Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!g43g2000cwa.googlegroups.com!not-for-mail From: "Neo" Newsgroups: comp.databases,comp.databases.theory Subject: Re: MultiValue Databases Date: 10 Jun 2005 14:01:06 -0700 Organization: http://groups.google.com Lines: 42 Message-ID: <1118435695.324678.250660@g43g2000cwa.googlegroups.com> References: <429d8fad$0$24496$da0feed9@news.zen.co.uk> <1117634793.359666.291580@f14g2000cwb.googlegroups.com> <1ihs91h81tkk2fknak6i4rf5ahu6v5c565@4ax.com> <1117687299.355928.200220@f14g2000cwb.googlegroups.com> <2a953$429f1c17$4528e7ad$3247@ALLTEL.NET> <1117729678.888997.235350@g44g2000cwa.googlegroups.com> <1118158988.399655.126370@g47g2000cwa.googlegroups.com> <42a5c843$0$13769$db0fefd9@news.zen.co.uk> <1118166394.893495.9820@z14g2000cwz.googlegroups.com> <42a6b195$0$12370$db0fefd9@news.zen.co.uk> <1118245146.123728.31340@g43g2000cwa.googlegroups.com> <42a71c62$0$23699$db0fefd9@news.zen.co.uk> <1118366499.007187.270560@g44g2000cwa.googlegroups.com> <1118421479.531213.185600@g14g2000cwa.googlegroups.com> NNTP-Posting-Host: 66.201.8.90 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1118437271 32037 127.0.0.1 (10 Jun 2005 21:01:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 10 Jun 2005 21:01:11 +0000 (UTC) In-Reply-To: <1118421479.531213.185600@g14g2000cwa.googlegroups.com> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g43g2000cwa.googlegroups.com; posting-host=66.201.8.90; posting-account=0cgMYwwAAAB-QanOAkBSIgPTzjTIpbMh Xref: dp-news.maxwell.syr.edu comp.databases:44829 comp.databases.theory:31463 > Not all constraints can be enforced in the Database, but the > fundamental ones are best done there (data types, foreign keys, not null). I agree completely. Currently xrdb implements the most basic one (referential integrity) better than RM. And xrdb model has no NULLs (the presense of a NULL in a modelling system is indicative of a flaw/limitation). Currently other higher level constriants, such as those available in RMDBs, need to be implemented in the application layer. With time, basic/common constraints will be integrated within xrdb implementation. Note, that RM tends think certain things have a uniform set of attributes while xrdb doesn't preassume that. The most fundamental/important constraint in a db is referential integrity. In this area xrdb implementation exceeds RM implementation. For example, look thru all the xrdb scripts posted in this thread to see that one doesn't find a single underlying reference to things. User has no access and thus little opportunity to corrupt them. On the contrary, looking thru the RM scripts, one sees underlying IDs and reference fields exposed thru out the scripts. In RMDBs, referential integrity is dependent on user and his skill level. For instance, he has to enter the right IDs in the script and he should enable the proper constraints. Ensuring referential integrity is automated in xrdb. Also as shown in the simple examples, RM solutions are more likely to requires schema updates and/or data transfers which increases the chances of corruption. The chances of finding a broken reference or redundant data not synchronized by constraints is much higher in RMDBs than xrdb. While constraints are important, the ability to model anything in a systematic manner is even more important (for some scope of applications such as AI). In that area, xrdb excels over RM, as can been in this thread. Notice that RM has to keep changing its schema/queries to handle new data and RM still hasn't posted script for some of the original queries rendered invalid by schema changes. Also note that in an attempt to be as flexible as xrdb, RM has to use generic tables/columns and constraint become more difficult. Ed, you stated you wouldn't have updated the RM schema as Johh did. Could you post your schema/script to store "John likes Mary", "John likes 111-1111", "Mary likes Fido" where Fido is a dog, "Fido hates Bob", phone#s with ext#s, specified queries, etc.