Good day everyone, First of all, I am fairly new to RoR and am currently reading "Agile Web Development with Rails" book to get me started. I guess I am a little confuse as why we are encouraged to use "ID" as a PK for most, if not all, our tables. In the book page# 206 (for those who has one), it talks about why ORDER table has a PK of ID instead of something such as order_number and some other meaningful column. Could someone explain to me why using "ID" as PK is a better solution than let''s say combining PKs from 2 different tables for a linking table? The book provides an example and reasoning for why we should use "ID" versus "ISBN" number as a PK for a table "BOOK". It says that if the ISBN formating were to change (assuming there is another table that reference rows in book table), we will have to drop the FK constraint, then update the ISBN in both tables and finally recreate the FK constraint. I seriously thought that this constraint is the point of implementing relationship between tables so that people cant just go in to the DB and start changing ISBN number without doing all the dropping FK, updating ISBN, etc? Please advise and thank you in advance, Will -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, 2006-11-05 at 18:38 +0100, Will wrote:> Good day everyone, > > First of all, I am fairly new to RoR and am currently reading "Agile Web > Development with Rails" book to get me started. I guess I am a little > confuse as why we are encouraged to use "ID" as a PK for most, if not > all, our tables. In the book page# 206 (for those who has one), it talks > about why ORDER table has a PK of ID instead of something such as > order_number and some other meaningful column. Could someone explain to > me why using "ID" as PK is a better solution than let''s say combining > PKs from 2 different tables for a linking table? > > The book provides an example and reasoning for why we should use "ID" > versus "ISBN" number as a PK for a table "BOOK". It says that if the > ISBN formating were to change (assuming there is another table that > reference rows in book table), we will have to drop the FK constraint, > then update the ISBN in both tables and finally recreate the FK > constraint. I seriously thought that this constraint is the point of > implementing relationship between tables so that people cant just go in > to the DB and start changing ISBN number without doing all the dropping > FK, updating ISBN, etc? > > Please advise and thank you in advance,---- it''s one of the things that rails defaults to in order to simplify things. Essentially, if the ''id'' is an untouched primary key without significance to the application itself, you are free to operate on all of the fields and editing a particular item itself is easily accomplished and at worst, you have one integer field extra. If the primary key is a field that you need to modify, then you have to do some gymnastics within your code in order to save the record (and all associated records) with a new primary key which sort of defeats the simplification that makes rails work. Once you start developing a rails application, it clicks in and it becomes obvious. Craig --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi Will: It''s not just a Ruby on Rails concept. This is well-travelled territory, here in this forum and anywhere else on the internet related to database programming. /both ways of doing it have their pros and cons. Google "primary key surrogate key" or "natural key surrogate key" or "intelligent key surrogate key" and you''ll find plenty of discussions espousing both sides of the issue. After that, it''s pretty much up to you to decide for yourself how to do things. c. Will wrote:> Good day everyone, > > First of all, I am fairly new to RoR and am currently reading "Agile Web > Development with Rails" book to get me started. I guess I am a little > confuse as why we are encouraged to use "ID" as a PK for most, if not > all, our tables. In the book page# 206 (for those who has one), it talks > about why ORDER table has a PK of ID instead of something such as > order_number and some other meaningful column. Could someone explain to > me why using "ID" as PK is a better solution than let''s say combining > PKs from 2 different tables for a linking table? > > The book provides an example and reasoning for why we should use "ID" > versus "ISBN" number as a PK for a table "BOOK". It says that if the > ISBN formating were to change (assuming there is another table that > reference rows in book table), we will have to drop the FK constraint, > then update the ISBN in both tables and finally recreate the FK > constraint. I seriously thought that this constraint is the point of > implementing relationship between tables so that people cant just go in > to the DB and start changing ISBN number without doing all the dropping > FK, updating ISBN, etc? > > Please advise and thank you in advance, > > Will-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hey Cayce, Thank you so much for responding to my questions. Your comment is really beneficial for me to move further with RoR development. Again, thank you so much for the insight. With much appreciation, Will Cayce Balara wrote:> Hi Will: > > It''s not just a Ruby on Rails concept. This is well-travelled territory, > here in this forum and anywhere else on the internet related to database > programming. /both ways of doing it have their pros and cons. Google > "primary key surrogate key" or "natural key surrogate key" or > "intelligent key surrogate key" and you''ll find plenty of discussions > espousing both sides of the issue. After that, it''s pretty much up to > you to decide for yourself how to do things. > > c. > > > Will wrote: >> Good day everyone, >> >> First of all, I am fairly new to RoR and am currently reading "Agile Web >> Development with Rails" book to get me started. I guess I am a little >> confuse as why we are encouraged to use "ID" as a PK for most, if not >> all, our tables. In the book page# 206 (for those who has one), it talks >> about why ORDER table has a PK of ID instead of something such as >> order_number and some other meaningful column. Could someone explain to >> me why using "ID" as PK is a better solution than let''s say combining >> PKs from 2 different tables for a linking table? >> >> The book provides an example and reasoning for why we should use "ID" >> versus "ISBN" number as a PK for a table "BOOK". It says that if the >> ISBN formating were to change (assuming there is another table that >> reference rows in book table), we will have to drop the FK constraint, >> then update the ISBN in both tables and finally recreate the FK >> constraint. I seriously thought that this constraint is the point of >> implementing relationship between tables so that people cant just go in >> to the DB and start changing ISBN number without doing all the dropping >> FK, updating ISBN, etc? >> >> Please advise and thank you in advance, >> >> Will-- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---