perlmeditation
herveus
Howdy!
<P>
I've been following the discussion on Inside Out objects
with considerable interest. The subthread about Flyweights
and the Flyweight design pattern further sucked me in.
<P>
I'm a database guy, so that perspective colors my perceptions
of how this concept maps into my world. I haven't noticed
mention of that angle (database). ...so here goes!
<P>
Let us consider a small relational model:
<P>
<PRE>
Entity Primary Key Attributes
Blazon Blazon_ID Blazon (which may be long)
Registration Registration_ID Date_Registered
Owner_Name_ID
Blazon_ID
How_Used
Date_Released
Name Name_ID Name (which may be longish)
...other attributes
</PRE>
Note that two of the attributes of a Registration are
foreign keys from the Blazon and Name entities.
<P>
One possible object interpretation of this data model
can be based around the Flyweight pattern. A Perl
implementation could use a blessed scalar for the object,
where the value of that scalar is the Blazon_ID, Name_ID,
or Registration_ID. The Blazon class implements the
Blazon table; it could have a real RDBMS backend, or it
could use some other persistence mechanism. Similarly for
the Name and Registraton entities.
<P>
For nuts-and-bolts access/update, object methods provide
access to the attributes/columns of the individual objects
(update). Class methods provide entity/table level access
(insert/delete/select). The class can provide caching as
appropriate.
<P>
...so where am I going with this?
<P>
If one looks at one's object model through a "relational
data model (normalized)" lens, many entities/tables are
strong candidates for this approach (flyweight and/or
inside-out).
<P>
A normalized data model tries really hard to follow the
dictum "each datum is recorded in exactly one place".
Multiple references to a specific datum need to be by a
"reference" of some sort, be it a Perl reference or a
foreign key relationship. It can be helpful to have the
key value be content-free -- an arbitrary value (often
numeric).
<P>
In the example above, one could have each class (Blazon,
Name, Registration) overload stringify to produce sensible
output (the Blazon, Name, or a string compounded of the
attributes).
<P>
OK. I'll admit that I've changed subjects on the fly (and revised my title about here). I'm
advocating that relational data modeling be kept in mind
when putting together a package that has complex data. Many
cases will only have a single entity class, but many others
will have multiple, interrelated entities. If you have a
data model that clearly describes your entities and their
relationships, you can then make informed choices that may
leave you with a denormalized implementation, but the key
is "informed".
<P>
yours,<BR>
Michael