views:

73

answers:

2

I was wondering if there is any reason to stay away from object serialization in PHP. My use case is for deferred processing. Ex: A mail queue where the mail object would be serialized when a send request is received, stored in a db and unserialized by a scheduled worker script.

The alternative is to store all the information that is needed by the object in the database and build the object in the worker script. The downside to this is that the database would be tied to the structure of the object and I do not want to do that.

A: 

Meet in the middle: for each mail object, serialize just the configuration array. The database does not need to be migrated with each mail-class change, and I imagine each database entry doesn't live long enough for you to see data migration issues.

Derek Illchuk
+3  A: 

The only real downside to serialization is that it has a performance hit. The performance generally scales with variable size; the larger your object, the more serialization time it will take.

That being said, it's hard to say which approach will be more performance-savvy here. You're going to take a performance hit for serializing and unserializing your objects, but on the other hand you'd have to re-build them. You'd have to benchmark each method against your average mail objects to get any hard data. As an aside, I'm not sure about your comment that storing the object data in the database ties it to the structure of the object... there's many ways to abstract that out.

That being said, there's no overbearing reason to stay away from serialization unless you demand extreme performance, in which case you'll likely end up doing all sorts of your own benchmarks anyway. It sounds like your serialization approach is straightforward and simplistic... I'd continue with it.

zombat
Agreed, performance is highly subjective and dependent on usage and data sizes (ie, how often is a given mail item requested? what is the distribution of large to small mail items)
r00fus
Thanks, that's good to know. And yes, the case that requires this is pretty simple and will not likely run into any performance problems. I was more thinking of creating something that's reusable in other contexts where performance might be important. But I'll tackle that when I get there.
rr