Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!news4.google.com!news.glorb.com!cycny01.gnilink.net!spamkiller2.gnilink.net!gnilink.net!trndny01.POSTED!9244eeff!not-for-mail From: "David Cressey" Newsgroups: comp.databases.theory References: <9OCTf.2923$1U1.813@trndny05> <2ISTf.3660$tN3.3129@newssvr27.news.prodigy.net> <1143343568.835480.20270@g10g2000cwb.googlegroups.com> Subject: Re: More on lists and sets Lines: 48 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: Date: Sun, 26 Mar 2006 18:58:36 GMT NNTP-Posting-Host: 71.127.4.129 X-Complaints-To: abuse@verizon.net X-Trace: trndny01 1143399516 71.127.4.129 (Sun, 26 Mar 2006 13:58:36 EST) NNTP-Posting-Date: Sun, 26 Mar 2006 13:58:36 EST Xref: dp-news.maxwell.syr.edu comp.databases.theory:37594 "dawn" wrote in message news:1143343568.835480.20270@g10g2000cwb.googlegroups.com... > RM and other models. But the reason is that the RM claims the > exclusivity with the Information Principle. If a data model has a big I don't think the Information Principle means "exclusivity" in this sense. > enough umbrella to permit composite structures other than relations, > then it seems that it is no longer the RM, right? It depends. A data structure can be "simple" in a relational sense, but "composite" in some other sense. VARCHAR is simple from the point of view of all the realtional operators. It's composite from the point of view of the substring operator (or function). I favor relational design where column domains are simple from a relational standpoint. But I don't object to the existence of a substring function embedded in the SQL. > > So, I am more than willing to agree that relations (e.g. functions) are > a good structure for modeling data, but I want lists too. It sounds > like we agree on this point, perhaps? We can coexist. If you want to treat the set of toppings on a pizza as a list in "your" program, go ahead. If I want to treat it as a set in "my" database it's not up to you to be offended, or disappointed, or to try to talk me out of it. If I want to treat the list of prior jobs of an applicant as a set, and you want to treat it as a list (or maybe even as a stack), neither one of us needs to prove the other one "wrong". Whether we can collaborate, more than just coexist, remains to be seen.