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.
Not that I need them for the project I had in mind; it's so small that
virtually any technique could be used. I was hoping I could learn
something I could scale to larger projects.
I was hoping for some special tools that would allow me to mark my
objects and their attributes so that the RDB was explicit. Guess I'll
have to roll my own. ;)
-- Darren Duncan
