Sign In
Create Account
Follow Us on Twitter
Subscribe on Youtube
Someone told me in the past that if I have a single field and put a serialized array of, say 30, elements in it into that field it would take up MORE space than if I put 30 complete rows in a table with that same info. And also that retrieving serialized data and doing anything with it is very slow.
Is this true? I think someone else said that it would be better to have the serialized data in one field. It just "seems" crazy to have 30 rows in place of one single field, but maybe he was right. I don't know. I already went to the trouble to change it to the way he said now though. And also since I have to select the data based on a word... it's better to have an index and have the separate rows. But I am still wondering if it is true that I am not using more space this way.
I guess I could do some test myself, but in phpmyadmin I've never paid attention to even notice how you can tell the size of a single field and not the entire table instead.
2 replies to this topic
Back to top|
|
|
#2
Posted 21 April 2009 - 02:16 AM
Orjan
-
- Moderators
-
- 3,298 posts
Writes binary right handed and hex left handed
Well, of course the serialized data is larger than the pure data, as it contains separators and other information. In my believe, I'd store pure data to an database. it can then treat it and work with it in other ways than you can with serialized.
of course, if there is absolutely no need to let a sql server deal with the information ever, it might be a solution, but I find serialization better for storing data in sessions or send it in GET or POST data than store it in databases.
The databases has normally a compacter storage of the information from pure data than store the serialized version, so I don't think the gain is very much.
on the other hand. normally, disk space is cheap and execution times and bandwidth are expensive, so, it's all about weighing things towards each other.
in my world, I'd store as pure data as possible in the db, as it's easier interpreted by the sql itself.
of course, if there is absolutely no need to let a sql server deal with the information ever, it might be a solution, but I find serialization better for storing data in sessions or send it in GET or POST data than store it in databases.
The databases has normally a compacter storage of the information from pure data than store the serialized version, so I don't think the gain is very much.
on the other hand. normally, disk space is cheap and execution times and bandwidth are expensive, so, it's all about weighing things towards each other.
in my world, I'd store as pure data as possible in the db, as it's easier interpreted by the sql itself.
__________________________________________
I study Information Systems at Karlstad University when I'm not on CodeCall
I study Information Systems at Karlstad University when I'm not on CodeCall
#3
Posted 21 April 2009 - 05:00 AM
BASHERS33
-
- Members
-
- 198 posts
Programmer
Thank you. I hadn't even thought about those separators, the counts of characters in the strings, etc... so it now makes more sense to me.
I see where the forum software I use serializes their cache table's arrays of info and some other things, but I am thinking I agree that it's not such a great idea. In my case I need to manipulate it sometimes so yes I am thinking I probably was wise to change it and not serialize it then.
I currently have nothing serialized at all in either of the programs I am working on so finally something I can hopefully leave the same! lol
I see where the forum software I use serializes their cache table's arrays of info and some other things, but I am thinking I agree that it's not such a great idea. In my case I need to manipulate it sometimes so yes I am thinking I probably was wise to change it and not serialize it then.
I currently have nothing serialized at all in either of the programs I am working on so finally something I can hopefully leave the same! lol
