ORACLE表设计:M:N表最佳实践

Question

我想听听你对这个基本问题的建议:

想象一下这三个表:

    --DROP TABLE a_to_b;
    --DROP TABLE a;
    --DROP TABLE b;
    CREATE TABLE A
      (
        ID   NUMBER NOT NULL ,
        NAME VARCHAR2(20) NOT NULL ,
        CONSTRAINT A_PK PRIMARY KEY ( ID ) ENABLE
      );
    CREATE TABLE B
      (
        ID   NUMBER NOT NULL ,
        NAME VARCHAR2(20) NOT NULL ,
        CONSTRAINT B_PK PRIMARY KEY ( ID ) ENABLE
      );
    CREATE TABLE A_TO_B
      (
        id         NUMBER NOT NULL,
        a_id       NUMBER NOT NULL,
        b_id       NUMBER NOT NULL,
        somevalue1 VARCHAR2(20) NOT NULL,
        somevalue2 VARCHAR2(20) NOT NULL,
        somevalue3 VARCHAR2(20) NOT NULL
      ) ;

你会如何设计表a_to_b？

我会给一些讨论开始:

• 合成id-PK列或组合a_id,b_id-PK(删除"id"列)
  • 合成时:还有哪些其他指标/约束？
  • 合并时:还在b_id上索引？甚至是b_id,a_id(不这么认为)？
  • 当这些条目被自己引用时也合并了吗？
  • 当这些条目未来可能被引用时,也会合并吗？
• 堆或索引组织表
  • 总是或只有x"somevalue" - 列？

我知道其中一个设计的决定与表格的使用方式(读/写比率,密度等)密切相关,但也许我们得到一个20/80的解决方案作为未来读者的蓝图.

我期待着你的想法!

Blama

Answer 1

我总是让PK成为你的例子中两个FK,a_id和b_id的组合.将合成id字段添加到此表没有任何好处,因为您永远不会根据其id的知识来查找行.

使用复合PK为您提供了一个约束,该约束可防止a和b之间的关系的相同实例被插入两次.如果需要允许重复条目,则在概念级别上您的数据模型存在问题.

您在幕后获得的索引(对于我所知道的每个DBMS)将有助于加速常见联接.b_id上的额外索引有时很有用,具体取决于您经常进行的连接类型.

正如旁注,我不会对我的所有合成pk列使用名称"id".我更喜欢a_id,b_id.它使管理元数据变得更容易,即使它有点额外的输入.