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数据库的结果转储为预期输出。因此，我们很容易构建相对复杂的测试用例。
另外，我们创建了乌蒂尔类差异，用于比较两个文件，这些文件将自动判断输出的正确性。
