Re: MultiValue Databases
From: John <no_at_email>
Date: Thu, 09 Jun 2005 18:12:21 +0100
Message-ID: <42a87879$0$23688$db0fefd9_at_news.zen.co.uk>
>
> []
>
>
> well said. but he has not chance of proof since his model is just a
> network datamodel.
>
>
>
>
> but adding tables and columns for a RM model is not the drastic change
> the Neo makes it out to be. For example rether than restructure the
> phone DB to add the "Bob likes Mary" data, i would suggest a table
> called LIKES with two attributes DESIRER and DESIREE as primay key.
> both would foreign key back to the persons table so you prevent
> illogical entries like "111-1111 likes neutral".
>
>
> The sad thing is this isn't new technology. It's old technology wrapped
> in windows clothes.
>
>
>
>
>
> Relational Model is not a market leader, since it isn't a product. It
> is the basis of many leading DBMS products. It is also the theoretical
> "leader" meaning it is the best general model known.
>
>
> By Jove, I think he's Got IT!
>
>
>
>
> I would prefer he post his theoretical arguements in
> comp.databases.theory first and leave comp.databases out of it for now.
> There are just too many newcomers to database theory here (in
> comp.databases) to see how bad neo's system really is.
>
> Ed
>
Date: Thu, 09 Jun 2005 18:12:21 +0100
Message-ID: <42a87879$0$23688$db0fefd9_at_news.zen.co.uk>
Ed Prochak wrote:
>
> John wrote:
>
>>Neo wrote:
>
> []
>
>>To prove that the data model is "more general" does not require examples >>ad nauseam, it requires proof.
>
> well said. but he has not chance of proof since his model is just a
> network datamodel.
>
>
>>I sympathise with Lee. These examples bear no resemblance to a >>real-world modelling task that I have encountered, simply because one >>normally works from a known spec rather than designing a few tables and >>adding extra information in a piecemeal fashion.
>
>
> but adding tables and columns for a RM model is not the drastic change
> the Neo makes it out to be. For example rether than restructure the
> phone DB to add the "Bob likes Mary" data, i would suggest a table
> called LIKES with two attributes DESIRER and DESIREE as primay key.
> both would foreign key back to the persons table so you prevent
> illogical entries like "111-1111 likes neutral".
I agree. I had to restructure it in order to be able to handle a query of "how are these two things related?". The query was pointless, but it was instructive to show that it could be handled.
>
>
>> >>This just isn't the way that you prove a point. You need to do it in an >>abstract and formal way rather than by these examples, usenet challenges >>etc. >> >>I admire your enthusiasm for your cause, and am very much a supporter of >>new technologies, the underdog etc.
>
>
> The sad thing is this isn't new technology. It's old technology wrapped
> in windows clothes.
>
>
>
>> ... If you are serious about this then >>get up to speed on the relational model and the supporting theory (read >>and absorb the whole of Date's intro to database systems for example). >>This will introduce you to the whole range of criteria against which a >>database will be judged. If xrdb is going to compete, it will have to be >>as good as or superior to relational DBMSs in every criterion. Like it >>or not, relational databases are the market leader and you'll have to >>know them inside out for your product to compete with them.
>
>
> Relational Model is not a market leader, since it isn't a product. It
> is the basis of many leading DBMS products. It is also the theoretical
> "leader" meaning it is the best general model known.
OK. I should have enclosed "Relational" in quotes.
>
>
>>Just from thinking about it, xrdb can be shown as better than relational >>databases when it comes to storing data or completely unpredictable >>structure. Your computer task would probably show that xrdb was neater >>for persisting this type of information. The problem is that someone has >>to retrieve that data, enforce integrity constraints on it etc. With a >>relational DB you can see a list of tables each of which contains atomic >>or encapsulated values and has regularly defined constraints on it. >>Trying to browse the xrdb hierarchy looks complicated enough using the >>tool you have developed; trying to write queries for it, reason about >>the structure, compare different entities etc could be nightmarish.
>
>
> By Jove, I think he's Got IT!
>
>
>>If I were you I would think about / do the above then produce an >>advocacy paper with formal justification for each of the claims. Post >>back here and I'm sure a lot of people will assess it for you. I am not >>a big one for ad hominem arguments, but I think you need to realise that >>you need to be very well-educated and experienced in this field to avoid >>looking like a tit compared with people that are. I hasten to add that I >>profess to be neither. >> >>John
>
>
> I would prefer he post his theoretical arguements in
> comp.databases.theory first and leave comp.databases out of it for now.
> There are just too many newcomers to database theory here (in
> comp.databases) to see how bad neo's system really is.
>
> Ed
>
John Received on Thu Jun 09 2005 - 19:12:21 CEST