At 12:52 PM 12/6/2001 -0600, you wrote: >Two unrelated tables should be allowed to have whatever column names >they want.
They most certainly can. R:BASE has no argument with that. >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. Please keep in mind that there is a difference between DBMS and RDBMS. R:BASE is one of only a small handful of RDBMS's, so I doubt that you have had experience with another one of these. You were probably using Microsoft Accident or SQL Server which should only be classified as a DBMS. Neither of these follow the true model that Dr. Codd created when he set forth to create his model. If you had the ability to have different data types for columns with a common name within the same database, how would you be able to utilize any of the advanced SQL functions that are available? How could you use a SUBTRACT command against 2 tables that have a column called "CustId" in which one is TEXT and the other is INTEGER? It just doesn't make sense. This would offer NO data relationship or integrity on a default level. If I have a glass of a substance and I call it water, and you have a glass of a substance and call it water also, but yours is really motor oil. All of a sudden, a third person that comes along sees 2 glasses, both called water, so, he decides to consolidate the two together, after all, why have 2 small glasses of water laying around, when you can put everything in 1 bigger container. Suddenly we have a mess, don't we? This scenario is as asinine as classifying an apple as an automobile. I think that you are looking at the database model on too small a scale. You see the tables as independent entities, which they are, but you fail to see that they are under the umbrella of being in the same database. >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. This makes little sense to me because proper design dictates that you provide for worst case scenarios. If I have the possibility of having an Employee with a 30 character first name, what would stop me from having a Customer with a 30 character first name? After all, I could own a supermarket, and my Employee could do his/her shopping there, hence becoming my Customer, right? So wouldn't it make sense to allow for the worst of the two? A true Left-Winged response to this would be: " If I want, Why can't I have FirstName be TEXT in one table, and INTEGER in another? It's a free world, isn't it?" Well, anyone thinking on that extreme missed their calling in life. Relational Database programming isn't for them. >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. Hmmm...You are using a RELATIONAL database system, but don't want a relationship. Sort of like ordering a steak if you are a vegetarian. Once again, doesn't quite make sense. I think you need to rethink your strategy. Mike ------------------------------------------- Michael Willochell Director, Customer Support R:BASE Technologies, Inc. 3935 Old William Penn Highway Murrysville, PA 15668-1854 Phone: 724-733-0053 FAX: 724-733-0196 URL: www.rbase.com Sales: [EMAIL PROTECTED] Support: [EMAIL PROTECTED] ------------------------------------------- ================================================ 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
