The only thing it helps is laziness. What is to be gained from enforcing columns having the same type/length if they have the same name? Being that no constraint is created, what is the point of enforcing that rule? Tables are private containers unless constraints are deliberately written against them. I don't want my application or database to do anything I don't tell it to do. And if I didn't tell it to do something, that's my fault and I should do it properly in the first place.
Does anybody write classes? C++/VB/JAVA, ETC. Imagine if your development environment made you create variables of the same type just because another class had a variable of the same name? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On > Behalf Of Alastair Burr > Sent: Thursday, December 06, 2001 2:57 PM > To: [EMAIL PROTECTED] > 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
