Wols Lists wrote: > On 13/12/10 01:38, Darren Duncan wrote: >> Darren Duncan wrote: >>> Wols Lists wrote: >>>> Dunno how well that approach translates into a relational engine, >>>> because Pick has several very non-relational quirks (every "row" MUST >>>> have a primary key, the dictionary DEscribes, not PREscribes the FILE, >>>> etc etc). >>> Can you say more about this last paragraph. These last couple items don't >>> necessarily mean that Pick is non-relational given how they can be >>> interpreted. >>> (I don't know anything about Pick.) >> Actually, nevermind. Google is your friend. -- Darren Duncan > > Pick is a jack-of-all-trades database - I describe it as being a bit > like C - it gives you all the rope you need to shoot yourself in the > foot :-) But it's best if used as an object-relational database. Pick > has FILEs and RECORDs instead of TABLEs and ROWs, and you can store > lists in a cell :-) > > 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 interested in reading more about this. Why don't you write up a blog post or an article, put it on your web site. You do have a web site, no? Hopefully, powered by an object-relational, non-Euclidean, file-and-record database, the pick of the litter ;-) Seriously, I would love to read more about this as I am interested in storage technologies for gridded data (think cells in a remote sensing image). For now, all I have is the image of Dick Pick hanging upside down in his anti-gravity shoes burned in my brain. -- Puneet Kishor http://punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --------------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =========================================================================== _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
