I believe George Forman named each of his sons George. I think that is just asking for trouble, if not now, later.
Bill Cook Kent WA USA ----- Original Message ----- From: "Alastair Burr" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 06, 2001 12:57 PM Subject: Re: Duplicate Column Names = Foreign Key... UGH > Perhaps you're right, Eric - if you want to be pedantic about it - but I > would suggest that there are many more times when having the data type the > same for columns with the same name helps rather than hinders. And, yes, I > have also wanted the same name for columns that are related but not the same > size in different tables before now and _always_ found that I could better > define one column to give me a more complete design overall. > > eg: with First_Names I might have chosen Short_First_Name and > Long_First_Name but could have ended up with Nick_Name and First_Name - or > something like that - more accurately defined rather than the same. > > Good luck, > Regards, Alastair. > > > > ----- Original Message ----- > From: "Eric Peterson" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, December 06, 2001 6:52 PM > Subject: RE: Duplicate Column Names = Foreign Key... UGH > > > > Two unrelated tables should be allowed to have whatever column names > > they want. If I create 2 classes of any time, each class has > > members/properties that are exclusive and private to their individual > > class or parent. Rbase is the only database I've dealt with that > > doesn't treat a table's columns as private members of that table. It is > > completely rediculous that I can't have a table named "Customer" and a > > table named "Employee" each containing a column named "FirstName", and > > be completely unrelated. Tell me how a Customer's first name, and an > > Employee's first name have anything to do with each other. If I want > > one to be 20 chars and one to be 30 chars, there should be no reason I > > can't do that. > > > > Your customer was right. This has nothing to do with relationships. I > > don't want a relationship between the two tables and my DBMS should not > > assume I do. > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > On > > > Behalf Of Mike Willochell > > > Sent: Thursday, December 06, 2001 12:21 PM > > > To: [EMAIL PROTECTED] > > > Subject: RE: Duplicate Column Names = Foreign Key... UGH > > > > > > At 11:23 AM 12/6/2001 -0600, you wrote: > > > >Why must tables who have the same column names have exact data types? > > > >Isn't it creating a foreign key relationship between the two? > > > > > > > > > Dear Eric; > > > > > > Some may wonder why it is that R:BASE forces the columns with > > > the same names to have the same data types. The answer is really > > > simple...True Relationship. This is what sets R:BASE apart from the > > > rest. > > > > > > I had a customer argue with me one time that this constraint was > > > not present in SQL Server. He said that this had nothing to do with > > > database relationships. He was very wrong. R:BASE was built on > > > Dr. Codd's theory, and still adheres to it today. How can you have > > > TRUE data integrity and relativity if the columns of the same name > > > have different data types? It is sort of like a family unit. > > > > > > Keys are a whole different subject. You can have 2 tables that have > > > columns by the same name, that have no key relationship. You > > > could enter any information into either of these tables, and nothing > > > would be verified against the other UNLESS you had a Primary and > > > Foreign Key relationship set up. With the keys in place, you could > > > not enter anything into the table with the Foreign Key without it > > > already existing in the table with the Primary Key. > > > > > > I hope this helps you to understand the reasoning behind it. > > > > > > Best Regards, > > > > > > RBTI Support Staff > > > > > > > > > ================================================ > > > TO SEE MESSAGE POSTING GUIDELINES: > > > Send a plain text email to [EMAIL PROTECTED] > > > In the message body, put just two words: INTRO rbase-l > > > ================================================ > > > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > > > In the message body, put just two words: UNSUBSCRIBE rbase-l > > > > ================================================ > > TO SEE MESSAGE POSTING GUIDELINES: > > Send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: INTRO rbase-l > > ================================================ > > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > > In the message body, put just two words: UNSUBSCRIBE rbase-l > > ================================================ > TO SEE MESSAGE POSTING GUIDELINES: > Send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: INTRO rbase-l > ================================================ > TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] > In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l
