Do not use serialialization for everything. You will downgrade RDBMS
to som 'simple' hash-table file like GDBM.
You will not be able to index, search and sort objects, which is the primary
reason for using RDBMS.
Just use serialization if use want to store some subtree of class hierarchy
in one table. Select primary atributes of superclass,
store them is some VARCHAR2 or NUMBER columns, make appropriate indexes and
constraints.
Then store a serialized object in one BLOB column. This will give you the
power of RDBMS when searching and sorting, but does not limit
the content of subclasses.
I use this principle with objects, which strcucture changes frequently.
Good examples are Session objects (on multi-application sites) or Message
objects in enterprise messaging systems.
Design your objects to have simple attributes that can be
stored in RDBMS columns.
Then write a select(), update(), delete(), ... methods, that will store
these simple attributes
in RDBMS columns. Object like this are restorored very quick, just make one
select, stuff results into hash and bless that hash.
You could even search for value of every attribute, sort it. If you will pay
enough attention to design of such objects,
all attributes will be stored in RDBMS in thier 'natural' format, for
example, dates will be stored as dates, not as a string that contain number
wich representns number of seconds since 1/1/1970.
And that is good, because you should run queries like 'gimme all data for
last week'.
Disadvantage is, that you must create special table for every subclass.
And there is another disadvantage - this kind of persistent object tends to
be very complex,
implementation very 'obfuscated' and they are extremnly difficult to
maintain consistent unless you desing them properly.
I use this kind of persistent objects for most of 'core', business-logic
objects.
I'm still looking for some way how to read an UML model and generate
object's attribute description directly from datamodel. But have no solution
on this yet.
For now, I use data definitions that look like this:
I use these definition to deternime correct RDBMS storage types (e.g. VARCHAR2 for 'String'-s), to validate user-provided value with regeexp prior to RDBMS update (e.g. 'identifier' means /^[\w\d_]+$/), and to select s correct type of HTML inputbox.%attrs = ( id => { storage => 'String', input => 'Text', syntax => 'identifier' }, realName => { storage => 'String', input => 'Text', syntax => 'text', }, password => { storage => 'String', input => 'Password', syntax => 'password', }, );
And the best way is to represent all of your objects in XML and store
them to some XML-database.
But XML-databases are rare in these early days of XML development
and representing your data in XML, storing them as XML, retrieving
them as XML and
rebuilding real perl object from XML could be very resourcers-expensive
task.
OTOH you will not deal with details about storing attribtes in database,
XML-DB will care about that.
Other application (non-perl) could perfectly read and understand your data.
You could store complex data structures (lists, trees) in database as a
single entry. Etc, etc ...
But this is kind of sci-fi to me. I have no time to try it out now, and I'm
affraid of XML performance penaulty.
First two schemas are implemented in Jewels Application Framework,
which is not released yet as it is still under heavy contruction. But if you
want to see a (undocumented) examples, there is some old, ugly and undocumented code
in download area of Jewels web page. Use at your own risk :-)
Hope this helps.
In reply to Re: storing serialized object in a database
by gildir
in thread storing serialized object in a database
by dshahin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |