Wols Lists wrote: > Personally, I believe relational *technology* is fatally flawed by > design - there's nothing wrong with the maths, but you can't do > astronomy with classical physics and you can't do large information > stores with set theory :-) > > I know that's flame-bait, but let's quickly explain ... > > I would say that a well designed Pick database uses the > object-relational paradigm. Each file is a class, each record is an > instance, and each record is a FULLY NORMALISED N-DIMENSIONAL ARRAY. > (Just not first normal form.) > > So my datastore is heavily influenced by the real world. And I can > reason about real world performance. All stuff that's forbidden in a > "real" relational database. And actually, I can prove that my default > performance is pretty close to a real relational database's theoretical > best. > > But all of that depends on a close tying between the logical structure, > the physical structure, and the real world. And all of that is totally > antithetical to the basis behind relational database theory. > > And building on that, I would actually conclude that, just as in the > real world parallel lines DO meet (Euclid's statement to the contrary > notwithstanding), I would also conclude that in the real world data does > NOT come just as rows and columns in sets (C&D's statement to the > contrary notwithstanding), but it also comes in lists, bags, and jumbles. > > I'm quite happy to carry on discussing this, either privately or on the > list, but there's a very good chance the list wouldn't welcome it ...
I am also very interested in these subjects. I believe that the relational model can accurately model anything in the real world, and that this can be implemented in efficient ways, with physical structure taking hints from logical structure. Also, that you can model any data structure simply over tuples and relations, including arrays and bags, and likewise implement such tuples and relations with physical arrays behind the scenes. Ordered lists and bags can be logically binary relations with index+value or value+count attributes. (That is also the canonical way to do it in Muldis D.) It is perfectly valid to nest tuples and relations inside each other (these *are* valid 1NF), and so likewise you can have record field values that are sets or arrays or tables or whatever. -- Darren Duncan _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
