Hello, Not sure if this is implied in the documentation or something given: does the RoR framework require "every table must have an id" ? If this is the case, then what happened to the concept of normalization ? Futher, if the tables have already been build for an existing appication ( without ID column in everytable ) , will the script / generate work ? Thanks -- Posted via http://www.ruby-forum.com/.
Hi ! 2005/12/27, Farooq <farooqm@myway.com>:> Not sure if this is implied in the documentation or something given: > does the RoR framework require "every table must have an id" ? If this > is the case, then what happened to the concept of normalization ? > Futher, if the tables have already been build for an existing > appication ( without ID column in everytable ) , will the script / > generate work ?Yes, all tables need an ID or equivalent column. It need not be called ID (see #set_primary_key http://api.rubyonrails.com/classes/ActiveRecord/Base.html#M000741). Normalization only ensures that the customer's address is not repeated in more than one table. That's why we use IDs to get at the customer's record. Never tried it myself, but script/generate scaffold should work with your existing tables. You will need to change the generated models to set your primary key, though. Hope that helps ! -- François Beausoleil http://blog.teksol.info/ _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Yes. Every table must have an ID, but I believe you could call it something else (mainly to assist with legacy tables). Normalization has nothing to do with not having an ID column. Normalization is a process the exists independent of the idea of a column called ID. You could do it with a meaningful column like social-insurance number. However, meaningless ID columns are a wiser choice. if you don''t have an id column then updates/edits won''t work. bruce On 27-Dec-05, at 11:47 AM, Farooq wrote:> Hello, > Not sure if this is implied in the documentation or something given: > does the RoR framework require "every table must have an id" ? If this > is the case, then what happened to the concept of normalization ? > Futher, if the tables have already been build for an existing > appication ( without ID column in everytable ) , will the script / > generate work ? > > Thanks > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On Tue, Dec 27, 2005 at 02:21:49PM -0500, Francois Beausoleil wrote: } Hi ! } } 2005/12/27, Farooq <farooqm-YbzV19J7KiEAvxtiuMwx3w@public.gmane.org>: } > Not sure if this is implied in the documentation or something given: } > does the RoR framework require "every table must have an id" ? If this } > is the case, then what happened to the concept of normalization ? } > Futher, if the tables have already been build for an existing } > appication ( without ID column in everytable ) , will the script / } > generate work ? } } Yes, all tables need an ID or equivalent column. It need not be } called ID (see #set_primary_key } http://api.rubyonrails.com/classes/ActiveRecord/Base.html#M000741). } } Normalization only ensures that the customer''s address is not repeated } in more than one table. That''s why we use IDs to get at the } customer''s record. } } Never tried it myself, but script/generate scaffold should work with } your existing tables. You will need to change the generated models to } set your primary key, though. Is there support for multi-column keys? I have a situation in which the most reasonable schema has a table with a two-column key: the pairing of a foreign key and an ordering value. It is a simple has_many situation, and there is no reason to interact with records of the model outside the dependent has_many collection. } Hope that helps ! } -- } Fran??ois Beausoleil --Greg
> Is there support for multi-column keys? I have a situation in which the > most reasonable schema has a table with a two-column key: the pairing of a > foreign key and an ordering value. It is a simple has_many situation, and > there is no reason to interact with records of the model outside the > dependent has_many collection.Not really, but you can get around it. I''d suggest using a normal primary key anyway, it''ll be a *LONG* time before you run out of IDs. -- rick http://techno-weenie.net