I'd like to hear your suggestions on this very basic question:

Imagine these three tables:

    --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
      ) ;

How would you design table a_to_b?

I'll give some discussion starters:

• synthetic id-PK column or 开发者_如何转开发combined a_id,b_id-PK (dropping the "id" column)
  • When synthetic: What other indices/constraints?
  • When combined: Also index on b_id? Or even b_id,a_id (don't think so)?
  • Also combined when these entries are referenced themselves?
  • Also combined when these entries perhaps are referenced themselves in the future?
• Heap or Index-organized table
  • Always or only up to x "somevalue"-columns?

I know that the decision for one of the designs is closely related to the question how the table will be used (read/write ratio, density, etc.), but perhaps we get a 20/80 solution as blueprint for future readers.

I'm looking forward to your ideas!

Blama

I have always made the PK be the combination of the two FKs, a_id and b_id in your example. Adding a synthetic id field to this table does no good, since you never end up looking for a row based on a knowledge of its id.

Using the compound PK gives you a constraint that prevents the same instance of the relationship between a and b from being inserted twice. If duplicate entries need to be permitted, there's something wrong with your data model at the conceptual level.

The index you get behind the scenes (for every DBMS I know of) will be useful to speed up common joins. An extra index on b_id is sometimes useful, depending on the kinds of joins you do frequently.

Just as a side note, I don't use the name "id" for all my synthetic pk columns. I prefer a_id, b_id. It makes it easier to manage the metadata, even though it's a little extra typing.

CREATE TABLE A_TO_B
      (
        a_id       NUMBER NOT NULL REFERENCES A (a_id),
        b_id       NUMBER NOT NULL REFERENCES B (b_id),
        PRIMARY KEY (a_id, b_id),
        ...
      ) ;

It's not unusual for ORMs to require (or, in more clueful ORMs, hope for) an integer column named "id" in addition to whatever other keys you have. Apart from that, there's no need for it. An id number like that makes the table wider (which usually degrades I/O performance just slightly), and adds an index that is, strictly speaking, unnecessary. It isn't necessary to identify the entity--the existing key does that--and it leads new developers into bad habits. (Specifically, giving every table an integer column named "id", and believing that that column alone is the only key you need.)

You're likely to need one or more of these indexed.

• a_id
• b_id
• {a_id, b_id}
• {b_id, a_id}

I believe Oracle should automatically index {a_id, b_id}, because that's the primary key. Oracle doesn't automatically index foreign keys. Oracle's indexing guidelines are online.

In general, you need to think carefully about whether you need ON UPDATE CASCADE or ON DELETE CASCADE. In Oracle, you only need to think carefully about whether you need ON DELETE CASCADE. (Oracle doesn't support ON UPDATE CASCADE.)

the other comments so far are good.

also consider adding begin_dt and end_dt to the relationship. in this way, you can manage a good number of questions about each relationship through time. (consider baseline issues)