Let's say I have a Database called Neighborhood. Under this database I have a table called Dog. My Dog table has a column called Bark. Bark is defined as CHAR(3) and consists of YES/NO. I have a second table called Tree. My tree table needs a column called Bark, which should consist of data describing the bark of my particular tree (to decided what affects the dog's urine may have on it), but I cannot do that because Rbase will only let me have a CHAR(3) column for Bark. I should not be required to name my column TreeBark, or DogBark as they are already described by the tables they are in. In response to your Water/Oil example, if you tried to perform functions cross referencing a Dog.Bark and a Tree.Bark, you have problems elsewhere.
And I cannot believe that you are making the statement that SQL Server is not an RDBMS. That hints to me you are prejudiced towards your old ways and tools, and unable to comprehend the glorious, illustrious, object orientated, client server wonder... <trumpet please> SQL SERVER. Hey candles worked fined, why bother with electricity? Eric > >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 ================================================ 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
