辅助表上更多的内容

　　在外键列上有索引吗？

SQL> select index_name， table_name， column_name， column_position 2  from user_ind_columns; INDEX_NAME   TABLE_NAME           COLUMN_NAME          COLUMN_POSITION ———— ——————– ——————– ————— SYS_C009823  DF_MOVIE_DISTRICT    DISTRICTID                         1 SYS_C009827  DF_MOVIE_STORE       STOREID                            1 SYS_C009830  DF_MOVIE_EMPLOYEE    EMPID                              1 SYS_C009837  DF_MOVIE_CUSTOMER    CUSTID                             1 SYS_C009841  DF_MOVIE_MOVIE       MOVIEID                            1 SYS_C009845  DF_MOVIE_TAPE        TAPEID                             1 SYS_C009850  DF_MOVIE_RENTAL      TAPEID                             1 SYS_C009850  DF_MOVIE_RENTAL      CUSTID                             2 SYS_C009850  DF_MOVIE_RENTAL      RENTDATE                           3 SYS_C009810  DF_CUSTOMERS         CUSTID                             1 SYS_C009813  DF_ORDERS            ORDERID                            1 SYS_C009816  DF_PRODUCTS          PRODUCTID                          1 SYS_C009819  DF_ORDERDETAILS      ORDERID                            1 SYS_C009819  DF_ORDERDETAILS      PRODUCTID                          2 14 rows selected.

 

　　输出内容意味着什么？你可以立即判断出这样一个事实，不是所有表上都有主键，有15个表，但这里只返回了14行（或如果使用distinct的话，只返回11行），为什么我们会知道这个结果？因为创建主键时会自动创建一个索引，如果你在载入脚本中禁用了所有的引用完整性约束，你还会怀疑什么呢？

　　Oracle推荐将索引列作为经常访问的关联列，常见的规则是索引列用于where子句，缺少索引，你应该怀疑“create  table”部分没有创建外键索引列。

　　下面的查询显示了带外键的表名/列名：

SQL> select a.constraint_name， b.constraint_type，  2  a.table_name， a.column_name 3  from user_cons_columns a， all_constraints b 4  where a.constraint_name=b.constraint_name 5  and constraint_type = ‘R’; CONSTRAINT_NAME  C TABLE_NAME           COLUMN_NAME —————- – ——————– ————- SYS_C009831      R DF_MOVIE_EMPLOYEE    SUPERVISORID SYS_C009828      R DF_MOVIE_STORE       DISTRICTID SYS_C009821      R DF_ORDERDETAILS      PRODUCTID SYS_C009820      R DF_ORDERDETAILS      ORDERID DFMOVIESTOREFK2  R DF_MOVIE_STORE       MANAGERID SYS_C009852      R DF_MOVIE_RENTAL      TAPEID SYS_C009851      R DF_MOVIE_RENTAL      CUSTID SYS_C009838      R DF_MOVIE_CUSTOMER    STOREID SYS_C009814      R DF_ORDERS            CUSTID SYS_C009846      R DF_MOVIE_TAPE        MOVIEID DFMOVIEEMPFK2    R DF_MOVIE_EMPLOYEE    STOREID 11 rows selected.

　　这是最终结果吗？怀疑被证实了，外键没有被索引。

　　从管理和维护角度来看，为什么只有两个约束是明确命名的而剩下的都是系统命名的？实际上是这个方案总共有51个约束，这里只是发生了两个命名的约束。

　　小结

　　从这次探索来看，工具如DataFactory或你自己编写的脚本最关键的地方是能够产生百万计的测试样本数据，如果不能保证引用完整性，或在数据建模方面的最佳实践，它有什么好处？如果你打算在应用程序上调试查询，测试数据需要反应应用程序如何使用它。如果你依赖于数据完整性，你的测试数据需要支持并遵从父表/子表关联关系。

　　从设计的立场来看，有两个最佳实践容易被违背，其一是外键列无索引，其二是3个主要项目（主键、外键和索引）没有明确的名字。第三个可能是在表上无主键，难道在每个表上都需要主键吗？不是！但大多数情况下，每个表都需要主键，即使没有主键，你也要知道为什么没有设置主键，换句话说，不规范的表应该是有意识的决定，而不是失败。