I have spend a lot of time meditating and trying out implementations of Perl object persistence in RDMB. Here are some of my findings:

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:

        %attrs = (
                id => {
                                storage => 'String',
                                input => 'Text',
                                syntax => 'identifier'
                },
                realName => {
                                storage => 'String',
                                input => 'Text',
                                syntax => 'text',
                },
                password => {
                                storage => 'String',
                                input => 'Password',
                                syntax => 'password',
                },
        );
[download]

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.

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.