Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!uninett.no!news.net.uni-c.dk!not-for-mail From: Troels Arvin Newsgroups: comp.databases.theory Subject: Re: The TransRelational Model: Performance Concerns Date: Thu, 11 Nov 2004 22:13:00 +0100 Organization: UNI-C Lines: 25 Message-ID: References: <1c92edeb.0411102354.45157060@posting.google.com> NNTP-Posting-Host: studmed.ku.dk Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: news.net.uni-c.dk 1100207552 4766 130.225.107.130 (11 Nov 2004 21:12:32 GMT) X-Complaints-To: usenet@news.net.uni-c.dk NNTP-Posting-Date: Thu, 11 Nov 2004 21:12:32 +0000 (UTC) User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Xref: dp-news.maxwell.syr.edu comp.databases.theory:28080 On Wed, 10 Nov 2004 23:54:59 -0800, Josh Hewitt wrote: > In my opinion, in its current form (as described in the appendix of > C.J. Date's "An Introduction to Database Systems (8th ed)" and the > published patent) the TRM is not a feasible candidate for implementing a > relational DBMS. Thanks for an interesting posting. IO-intensiveness of insertions in TRM seems rather unavoidable. But I thought that some of the IO overhead in searches could maybe be avoided by adding some kind(s) of indexes to the model? I know that this sounds rather strange, because one of the ideas of TRM seems to be that all columns are clustered, enabling (somewhat) quick searching by "themselves". Another thought: All your examples seem to be use of fully projected relations, corresponding to SELECT * FROM ... Maybe TRM has value if most of the actual queries project to only a fraction of the existing columns? -- Greetings from Troels Arvin, Copenhagen, Denmark