On Wed, Jun 02, 2010 at 10:24:12AM -0700, Darren Duncan wrote: > Shawn H Corey wrote: >> I want to thank all those who responded. Your comments have given me a >> view of the state of the art as it currently exists. >> >> And from what I gather, it sucks. There is a lot of software that >> stores objects in a RBD and they do a good job. The problem is that >> while there the models for objects are well-formed, normalized >> relationships, there are no relations about the data in the objects. >> Concepts like primary key and foreign key are not part of Moose and >> without them, building a reliable RBD is very difficult. > > The concepts of keys very much are part of Moose if you do your abstraction > right. > > This also reminds me of something important that I neglected to say > earlier in the thread. Stevan, I hope this better lays out what I was > proposing before. > > Have you ever had a Moose object X that represented a homogeneous > collection or a list or a set of Y? That object X probably contained a > list of other objects Y, each of which represented a single thing Y. > > Moreover, when you had a Moose object representing a collection, it might > have had a uniqueness constraint built-in, such that some aspect of each > Y in an X had to be mutually distinct. In a general case, this could > mean that each Y as a whole had to be distinct from every other Y in an > X. Either way, each Y is distinct somehow so that if you wanted to pick > it out from the X you have a way of specifying which of the Y you want. > > Well, in a relational database, a whole relation/relvar/table/rowset X > represents an X object and each tuple/row Y of that represents a Y > object. > > A unique/primary/candidate/alternate key/constraint of a relation is > nothing more than a shorthand for a generic X type constraint with > particular properties, one that tests if the count of unique elements in > a collection is equal to the count of all elements in a collection. > > So, unless you never have a Moose object representing a set, you can't > say that a relational database doesn't directly correspond to that. To > be specific, each relvar/table is conceivably a variable which holds one > of said X objects, and you can have more than one variable at a time with > an X object. > > As for "foreign keys", we step back further to look at that. > > Have you ever had a Moose object Z such that each of its attributes is an > object representing a homogeneous collection such as a Y object is? And > have your object Z ever had a type constraint that restricts some > attributes by some other attributes, say that if one attribute P is > nonempty then another attribute Q must also be nonempty? > > Well, an entire relational database Z represents a Z object, or > specifically it is a variable that holds a Z object, and each > relvar/table attribute of the database corresponds to some given Y/etc > object that is an attribute of a Z object. > > A "subset constraint", which I consider a better term than "foreign key", > is nothing more than a shorthand for a generic Z type constraint with > particular properties, one that tests that, loosely speaking, the set of > elements defined by one Z attribute P is a subset of the set of elements > defined by another Z attribute Q. > > So, unless you've never had a Moose object whose attributes are sets/etc, > you can't say that a relational database doesn't directly correspond to > that. > > And, before people start saying "but ... but ...", I want to be clear > that the relational model lets you recursively nest relations/tuples as > attributes of others, to any depth. You don't have to split them off to > other relvars/tables, though that might be convenient, and even if you > did, you could unnest them together when doing queries so that all your > Perl/etc sees is everything nested together just like their objects. > Some SQL DBMSs even support nesting natively (such as Postgres and > Oracle), though not all, in which case you could pretend they did with > some Perl glue. > > Thinking about things this way, that an entire database or table is > itself an object, is why in my Muldis D language (translatable to both > SQL and Perl), these things are defined using ordinary type definitions.
Unless I'm missing something, this isn't what's being argued here though. Nobody is saying that relational data can't be modeled as perl objects - this is exactly what Fey::ORM and DBIx::Class do. Modeling arbitrary perl objects (including inheritance, etc) as database tables is a much harder topic, and what KiokuDB is intended for (although with the tradeoff of losing some traditional methods for manipulating the raw database). -doy
