Forum Moderators: coopster

Message Too Old, No Replies

serialize / unserialize

Under what circumstances should one use these functions?

         

neophyte

3:25 am on Nov 6, 2008 (gmt 0)

10+ Year Member



Hello All -

I've been looking at some examples of serialize / unserialize on various php tutorial sites, but can't quite wrap my mind around when it is advantageous to use these functions.

One thing that comes to mind is information storage into a db... for example:

I've got a form section in a current project that spans 4 pages - a lot of form information for a user to input.

Once the user completes the entire section, the submitted information is CURRENTLY added to 97 different fields across 4 database tables. But... I'm now thinking... I suppose I could serialize all of this information before it's added to the database and then simply add the serialized data into a SINGLE (text) field in a SINGLE table - 2 fields (one for the row ID and one for all of the form data) and 1 table vs 97 fields and 4 tables. If this is a possible scenario for the use of this function, I'd really like to know if a lot of the professions here do it this way.

The foregoing is only one approach I've considered for these functions, what are the other (non-OOP ... I haven't done any OOP work yet) ways to use this function?

Appreciate all responses.

Neophyte

Sekka

12:42 pm on Nov 6, 2008 (gmt 0)

10+ Year Member



I use serialisation to save time and processing mainly.

An example. You could have a really complicated piece of code that parses a lot of data into an object or array. If this data remains fairly constant, instead of doing this every request, you could serialise the generated object/array and instead use that. This way, you can skip the unrequired processing and start with the generated object/array.

Another example is based on OOP. If an object is being created over multiple forms on multiple pages, you could serialise the object and store it into the session so it is there on the next page to keep adding to.

There are a lot uses and right/wrong use is probably determined by your requirements.

As for your example, I would say no to what you want to do. What if down the line you decide to use the data differently? What if you want to index the data in the tables for performance? Neither would be easily done without separate fields.

I hope my rambling has helped in some way. Sadly, I'm not an expert on the subject.

cameraman

3:24 pm on Nov 6, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I agree with Sekka; I wouldn't use it for 'permanent' storage in a table - you can't easily search or use the data for selection criteria (in a where statement) if it's all stuffed into one field.

It is handy for temporary storage, for example to save in SESSION or in a session type table while the visitor is in between the 4 pages of data entry. Is that where your 4 tables come from? If true then you may be able to better optimize the 4 tables' worth of data into fewer tables although you may still wind up with 97 fields.

The processing for page 1 would validate the data, possibly sanitize it, then you just:
$_SESSION['p1'] = serialize($_POST);
and it's saved. Keep doing that through to page 4, then retrieve it all and manipulate it to insert into however many tables make sense to use.

neophyte

2:02 am on Nov 7, 2008 (gmt 0)

10+ Year Member



Sekka and Cameraman -

Thank you both for your replies - now I've got a better understanding of when and why these functions would be used.

Greatly appreciate your input!

Neophyte