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
