implode/explode vs serialize/unserialize

[bill]

Would one of the more knowledgeable folk discuss when it is
appropriate to use implode/explode and when it is appropriate to
use serialize/unserialize.

It seems that for 1D arrays implode is better in that is only
adds 1 character per array element and serialize adds many.

For objects, serialze is the only way to go.

in between ?

bill

[Jerry Stuckle]

There is no correct answer to your question without a context. The two
have entirely different purposes.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================

[Erwin Moller]

That is a vague question without more context.
Shooting from the hip I would suggest you use serialize only if you need
to store/transport a complex structure.
And use implode and explode only when you want to create a string from a
simple array (no arrays in arrays), and the other way around.

Try the following:

==================================
$a = array( array(1,2,3),array("a","b","c","d"),array("nr1"=>42,"nr2"=>9));
$str_impl = implode($a);
$str_ser = \serialize($a);

echo $str_impl;
echo "<hr>".$str_ser;
==================================

You will see implode makes no sense on (complex) $a.
Implode can only glue arrayelements together.
Serialize can create a string that is suitable to transport/store
complex structures that can later be unserialized.
You can not store volatile stuff with serialize, like filehandles,
databaseconnections, etc.

So, in short: implode/explode is NOT serialize/unserialize.

Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

[Erwin Moller]

On 5/29/2012 4:19 PM, Erwin Moller wrote:

<snip>

> ==================================
> $a = array( array(1,2,3),array("a","b","c","d"),array("nr1"=>42,"nr2"=>9));
> $str_impl = implode($a);
> $str_ser = \serialize($a);

typo correction:
the above should be without the \
thus:
$str_ser = serialize($a);

[Thomas 'PointedEars' Lahn]

bill wrote:

> Would one of the more knowledgeable folk discuss when it is
> appropriate to use implode/explode and when it is appropriate to
> use serialize/unserialize.

That is a stupid question, bill #256234 (no pun intended).

In fact, it is not a question at all.

> It seems that for 1D arrays implode is better in that is only
> adds 1 character per array element and serialize adds many.

And if any array element contains the delimiter, …

> For objects, serialze is the only way to go.

To go where?


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

[bill]

On 5/29/2012 10:19 AM, Erwin Moller wrote:
> On 5/29/2012 3:24 PM, bill wrote:
>> Would one of the more knowledgeable folk discuss when it is
>> appropriate
>> to use implode/explode and when it is appropriate to use
>> serialize/unserialize.
>>
>> It seems that for 1D arrays implode is better in that is only
>> adds 1
>> character per array element and serialize adds many.
>>
>> For objects, serialze is the only way to go.
>>
>> in between ?
>>
>> bill
>
> That is a vague question without more context.
> Shooting from the hip I would suggest you use serialize only if
> you need to store/transport a complex structure.
> And use implode and explode only when you want to create a string
> from a simple array (no arrays in arrays), and the other way around.
>
>

Erwin,

Your shot from the hip is exactly what I was looking for - thanks.

As a learner of PHP, the context is that both are used to convert
arrays to a form that can be stored in a mysql database.

bill

[Jerry Stuckle]

Which would violate rdb normalization rules...

[Erwin Moller]

If you want to store the content of arrays in your database, I suggest
you have another look at your current approach. I think you are heading
the wrong direction.

You haven't stated exactly what you are trying to achieve, but I think
you don't want to implode an array and store that as a string.
While it is possible, it will be harder for you to later retrieve the
info, or join it to another table, or group it, etc.
Actually all regular database actions I can think of would benefit from
the normal approach, which I describe below:

Imagine a table that stores answers that people gave you for your online
poll.
You ask 3 questions:
q1) Rate my site's layout (1=poor, 2,3,4, 5=great)
q2) Rate my site's content (1=poor, 2,3,4, 5=great)
q3) Rate my site's structure (1=poor, 2,3,4, 5=great)

BAD STORAGE:
You can create a table like this:
CREATE TABLE tblPollAnswers(
visitorid integer PRIMARY KEY,
impl_answers TEXT
)

The visitorid is just some imaginary unique number. It isn't important
for the example.
Now, if you implode the answers to the questions, you end up with
content that might look like this:

SELECT visitorid, impl_answers from tblPollAnswers;

visitorid impl_answers
22 "2,4,1"
24 "1,2,3"
44 "5,3,3"
443 "1,1,1"
598 "1,4,3"
etc.
Now try to figure out what the average rating for q1, q2 or q3 is.
You'll have to rip apart the string in impl_answers, make an integer of
it again, sum them, etc.
It is messy and errorprone.

GOOD STORAGE:
CREATE TABLE tblPollAnswers(
visitorid integer PRIMARY KEY,
questionid integer,
answer integer
)

SELECT visitorid, questionid, answer from tblPollAnswers;

visitorid questionid answer
22 1 2
22 2 4
22 3 1
24 1 1
24 2 2
24 2 3
44 1 5
44 2 3
44 3 3
etc.

Now you can easily access, group, etc all data.
eg:
Select questionid, AVG(answer) FROM tblPollAnswers GROUP BY questionid;

While the second approach might look more complicated on first
inspection, it is much much easier in the long run.
I would also advise to get a good book on the basics of databases and
how to design them. The basics are not rocket-science at all.

I hope this helped.

Good luck

[Thomas 'PointedEars' Lahn]

bill wrote:

> On 5/29/2012 10:19 AM, Erwin Moller wrote:
>> On 5/29/2012 3:24 PM, bill wrote:
>>> Would one of the more knowledgeable folk discuss when it is
>>> appropriate
>>> to use implode/explode and when it is appropriate to use
>>> serialize/unserialize.
>>>
>>> It seems that for 1D arrays implode is better in that is only
>>> adds 1
>>> character per array element and serialize adds many.
>>>
>>> For objects, serialze is the only way to go.
>>>
>>> in between ?
>>>
>>> bill
>>
>> That is a vague question without more context.
>> Shooting from the hip I would suggest you use serialize only if
>> you need to store/transport a complex structure.
>> And use implode and explode only when you want to create a string
>> from a simple array (no arrays in arrays), and the other way around.

Utter nonsense.

> Your shot from the hip is exactly what I was looking for - thanks.

No it is not. The problem with that approach is that implode() is _not_
generally reversible with explode(), even in a simple, one-dimensional array
where all elements are of the same type.

It does not work if the array elements are of different type or are not
strings (because the values are type-converted to string, and exploding a
string results in array of string elements), and it does not work if the
delimiter (say, `,') is part of any array string element, assuming that all
values are strings already. And if you knew exactly what was in an array,
you would not need to implode() it in the first place.

So if you want to preserve a data structure in string form for later
restore, use serialize() and unserialize(), nothing else.

[Scott Johnson]

Yes I tried that before while experimenting.

I got lazy and just create a 'user_data' field to store some form data
without creating an actual field for each one.

Well it worked just fine and danady until I needed to do a search for a
particular value.

I then had to pull ALL the data, deserialize and search that data.

What a nightmare. But I did learn some new algorithms in the process.

I suppose sometimes it is our failures that teach us the best.

:)
Scotty

[Jerry Stuckle]

On 5/30/2012 4:35 PM, Scott Johnson wrote:
> On 5/30/2012 9:57 AM, Jerry Stuckle wrote:

<snip>

>> Which would violate rdb normalization rules...
>>
>
> Yes I tried that before while experimenting.
>
> I got lazy and just create a 'user_data' field to store some form data
> without creating an actual field for each one.
>
> Well it worked just fine and danady until I needed to do a search for a
> particular value.
>
> I then had to pull ALL the data, deserialize and search that data.
>
> What a nightmare. But I did learn some new algorithms in the process.
>
> I suppose sometimes it is our failures that teach us the best.
>
> :)
> Scotty

Scotty,

Yup, there are reasons for those rules, and good reasons to follow them! :)

That doesn't mean you should always follow every normalization rule
every time; there are good reasons why you might not (i.e. performance).

But when you do violate the rules, you should have a good reason and be
aware of the possible consequences. After all, having to later change
the database and rewrite the programs can be a long, involved process!

[Scott Johnson]

On 5/30/2012 2:37 PM, Jerry Stuckle wrote:
> On 5/30/2012 4:35 PM, Scott Johnson wrote:
>> On 5/30/2012 9:57 AM, Jerry Stuckle wrote:
> <snip>
>>> Which would violate rdb normalization rules...
>>>
>>
>> Yes I tried that before while experimenting.
>>
>> I got lazy and just create a 'user_data' field to store some form data
>> without creating an actual field for each one.
>>
>> Well it worked just fine and danady until I needed to do a search for a
>> particular value.
>>
>> I then had to pull ALL the data, deserialize and search that data.
>>
>> What a nightmare. But I did learn some new algorithms in the process.
>>
>> I suppose sometimes it is our failures that teach us the best.
>>
>> :)
>> Scotty
>
> Scotty,
>
> Yup, there are reasons for those rules, and good reasons to follow them! :)
>
> That doesn't mean you should always follow every normalization rule
> every time; there are good reasons why you might not (i.e. performance).
>
> But when you do violate the rules, you should have a good reason and be
> aware of the possible consequences. After all, having to later change
> the database and rewrite the programs can be a long, involved process!
>

No doubt brother.