I tend to agree with Dae. It doesn't matter if my app will hit the 10,000,000,000 id number. It's a matter of doing "the right thing". Say I have an Invoice and InvoiceLines. I REALLY want my invoice lines to be structurally (I mean in the DB schema) dependent to the Invoice. I think (and all my DB teachers think the same) that it should exist a VERY, VERY good reason for not doing it like that. And the only reason I've ever come across is when I have a really deep dependency structure. I mean more than 3 or 4 levels. Then, yes. I eventually create a one-to-one mapping using a unique id to reference a complex composed key.
I know that supporting composite keys is not a MUST, but it's a SHOULD. I understand ActiveRecord doesn't support it now in favor of simpleness, but aventually it should have that option. Diego 2006/2/18, Dae San Hwang <[EMAIL PROTECTED]>: > > On Feb 19, 2006, at 4:12 AM, Kevin Clark wrote: > > > You'd really run 10,000 forums out of one database with shared tables? > > The argument is for the sake of argument. If you're that successful, > > you wouldn't make that choice. > My point was really that usage of surrogate id's can quickly become a > problem when the data model is nested like that. (id's at the end node will > increase exponentially.) > > daesan > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > > _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
