Re: Composite Key

Bill Lazar
Sat, 15 Oct 2005 23:06:24 -0000

Not a flame to me, not like you have to agree with me ;) Anyway, I''m so
new to Rails noob is too kind so my point is not from a RoR perspective but
rather general database design which I do have reasonable experience.

First, to suggest in 2005 that any but the absolutely largest databases need to
worry about wasting a couple of bytes per record will never work with me. If the
space for the ID and its index adds even 10GB per year call me and I''ll
send you the $3.00. (Bill is being facetious here.)

Second, if you choose Mark''s approach and avoid the model and
associated built-in reduction in code and complexity than I would argue
you''re spending developer and QA resources rather than disk space. If
that''s what you want, okay, but be clear about it. I think you would
lose quite a bit of other help (code that depends on AR and id=PK) so be aware
of the tradeoff.

Finally, I think this choice was made by DHH and the other developers because
they''re aware of the 25 year history of debate over DBMS design. If you
look at guys like Celko or Date, they usually go this way (look for
"synthetic candidate keys" in the theoretical discussions) and I will
defer to their authority.

YMMV,
Bill


Ron DiFrango wrote:
> Bill,
>
> My intention here is not to start a flame war, but the issue of composite
keys is one limitation that has given me some pause about RoR.  I will say, it
has made me look back over my data model [which I control to a large degree in
one of my projects] and see if my composite keys make sense and a truly
necessary.  My initial reaction was yes they were absolutley necessary, but
after a critical look all but the following scenario could fall under the RoR
way execept my "Rules" table.
>
> Here is the situation, I have a table called selections which has an
identity column called selections_id.  On this table there is also a column that
tells me whether or not the pricng for selection is rule based.  If it is, then
I have code that typically says, I have a group of selections that together in
some combintation make up the price for the selection.  On the rules table I
have 3 ID columns which are actually foreign keys back into the selections
table.  Since they are unique combinations, I just utilize all 3 of them as my
primary key on the table.
>
> Now, I could add a column that is an ID column to the table, but in my mind
it is a waste of space because it is nothing more than a placeholder just to
satisfy RoR.
>
> I will say that in most if not all the enterprise app I have worked on we
have had Composite Keys that in my opinion were absolutely necessary and fall
under this category where you are combining keys from either multiple tables or
there unique combinations yeilded something different.  I think for RoR to truly
succeed, it needs built-in support for not only Composite Keys, but quite
possibly those that are character based as well.
>
> With that said, I am in the process of attempting a conversion from a J2EE
architecture [JSP/SOFIA - Web framework/Hibernate/EJB, etc.] to RoR.  Wish me
luck!
>
> Ron