Database Practice
1.0.0
該項目的結構如下：
對於項目源文件的包裝，由以下合理安排：
為了將選擇推向我們的邏輯計劃中的適當位置，我們實施了聯盟查找數據結構，以分組具有相同範圍的條件的屬性。選擇條件包含一個關係和一個關係之間的次要，次要的表達，在一個關係之間的數字或相同關係的兩個屬性之間的選擇條件將在聯接條件後推下。 Uneqality和其他可用的選擇條件將被推到聯接操作員。
我們創建了一個名為SelectionOptimizer的類，以處理使用哪種選擇方法。我們首先檢查選擇中涉及的一個關係的所有屬性的索引可用性。如果這些屬性沒有適當的索引，我們將選擇普通的掃描方法。如果這些屬性有索引選項，我們將比較其成本，並選擇成本最低的成本。
我們在植入動態編程方法方面遇到了一些問題，以選擇最佳的聯接順序。我們實施的折衷解決方案是根據每個表大小選擇加入順序。
如果適用，我們的邏輯是使用Sort Merg加入。如果SMJ不適用，我們選擇使用嵌套循環加入。
該程序的頂級條目是在client.sqlinterpreter.main（）上。
解釋器負責讀取輸入文件並將其傳輸到查詢評估器，最後將結果輸出到文件。
我們將來自Where子句的條件分為：1。常數之間的比較。 2。餐桌選擇條件。 3。跨桌連接條件。
在解析開始時，所有條件都是通過遞歸分解和表達式提取的。然後，對於每個表格，我們記錄：1）其選擇條件，以及2）與所有前表的連接條件。這樣，我們可以沿著桌子移動，只專注於需要與當前左子樹連接的新表格時相關條件。當然，在一切之前都要處理持續的條件。
我們按照說明實現了分類器。如果未投影某些有序元素（例如，SB從s訂單中選擇SA），並且需要不同，則我們將使用另一個操作員使用標籤來維護訂單。
我們提供了一個Bplustree類，其構造函數能夠從給定的關係數據上構建一個序列屬性上的序列化索引文件。當用戶需要在執行過程中使用索引掃描運算符時，它還提供了樹索引避難所功能。這將縮短元組搜索時間。
我們使用B+樹索引實現了用於選擇索引選擇的索引掃描操作員。它評估表達式包含索引屬性，並將調用Deserilizer從B+樹的葉子節點中獲取第一個飽滿的數據輸入。之後，如果文件被群集，其他明智的明智，它將線性獲取，它將繼續從Deserializer獲取下一個滿意的數據輸入。
在以前的設計中，我們給了邏輯選擇操作員一個重要的限制，即邏輯選擇操作員的孩子必須是掃描操作員。因此，當我們使用訪問者模式構建我們的物理計劃時，我們最多只需要遍歷選擇操作員即可。當訪問者穿越選擇操作員時，邏輯可以決定選擇操作員的孩子應為完整的掃描操作員或索引掃描操作員。
當我們將信息從配置文件存儲到目錄中時。首先，如果數據庫目錄顯示索引查詢已打開，我們應該檢查此查詢中的索引的可用性。
我們有一種稱為HasidXattr的方法，該方法檢查索引是否適用於選擇條件。也就是說，如果該表的選擇條件大於大於等於，小於等於索引的attraibute的選擇條件，那麼我們可以構建索引掃描操作員為孩子。然後，我們計算LowKey和HighKey取決於所有選擇條件，然後構建操作員。
如果HasidXattr返回false，我們應該構建正常的完整掃描操作員。
最後，我們返回高度級別。
我們利用兩個測試策略
對於基本測試，我們手動構建操作員並傾倒元組，以證明操作員可以在迭代器模型方面使用。
端到端測試是測試，該測試將整個解釋器作為正在進行的單元進行測試。測試用例將獲取輸入查詢文件，然後執行查詢，最後將結果打印到目標文件中。
為了更好地進行測試，我們編寫了一個BASH腳本，該腳本將MySQL數據庫的結果轉儲為預期輸出。因此，我們很容易構建相對複雜的測試用例。
另外，我們創建了烏蒂爾類差異，用於比較兩個文件，這些文件將自動判斷輸出的正確性。
