Don't know off the top of my head; you could definitely test it using Benchmark. You could test something like Class::DBI against a hand-rolled solution using Storable and DBI.> I suppose the key question is, is there a big > performance boost in grabbing the serialized object, > rather than constructing a new instance out of the > stored data?
Hate to say it, but it really depends on your application. If you have an application where you need to search on the fields in your object/database, you shouldn't be serializing your data.
On the other hand, one thing you gain by storing a serialized object is that you don't have to worry about the columns in your table. If you add a new attribute to your object, you don't need to worry about database, etc.
You also said:
Yes, you do. And in some cases that's a real drawback. You don't want to have to load every object in the database then search through them w/ Perl, just to get back the objects you want. That's ugly and a memory hog and is just the sort of thing you want to avoid.> If not, then it seems like you give up the ability to search > the stored fields if you just serialize.
In my experience I very often find situations where I do want searchability, but YMMV.
The situations where serializing works well is where the only thing you'll ever want to search on is some sort of primary key ID. Session data, for example: if you store sessions in a DB and give out IDs for each session, your session layer really doesn't care what's in a session; and your app layer usually doesn't need to search on anything other than the session ID. So it makes a lot of sense to bundle up your data into a serialized stream and store it in the database, then thaw it in your session layer when you pull it back out. Object goes in, object comes out.
An example of needing searchability is when you have lots of different columns that you may need to search on. For example, you might have a "document record" stored in a DB, and you may need to search by author, title, body, last modified, etc. Here you *really* don't want to serialize your data, because you're just going to end up with a mess of Perl code sorting through the objects, where you really should let your database do that work.
Pointers to modules. If you want to store unserialized data in a DB--column maps to attribute, row maps to object, etc.--take a look at Class::DBI. I've not used it because I have a DB-object layer of my own that I use, but it's reputable, I believe. :) Update: Also check out Tangram.
For serializing, you could take a look at Apache::Session, which is a good way of managing session data through various interfaces (file, DB, etc.).
In reply to Re: storing serialized object in a database
by btrott
in thread storing serialized object in a database
by dshahin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |