Welcome!

[Johnathan]

Hello, I'm looking to cut my databases down a bit and for stuff like user settings, (name, email address, language etc) I was just going to have an array with everything in it so it would only take one field in a table. First I wanna ask is this worth it since it's having to get everything if all it wants is a name where if everything was in it's own cell, it would just take the data it needs?
Second question... How exactly would I do it? I've been playing a bit but not sure how to put the array into the database so it comes back out and I can select it like $array['name'];
Could someone just give me a sample that they have that puts the array in and takes it out again, shouldn't need to explain it. Only thing that needs explaining is he performance issue thing.

Thank you

PHP btw

[schrute]

If that's the route you're going, you're going to want to take a look at the serialize() and unserialize() functions for arrays.

http://php.net/serialize
http://php.net/unserialize

[Andy]

Terrible idea. You should look into normalizing your database instead.

This goes against the very first normalization form which states that all values should be atomic.
Furthermore, it wouldn't be worth it as you'd probably have more load with the serialization/unserialization than you would with letting the DBMS do its job. Most DBMS have cache, you know..

You should normalize up to at least 3NF.

[Johnathan]

Ok, the reason behind me thinking about it was I'd heard a few people saying that it's better that way when there are a lot of settings for each reader, having 10 values in an array instead of an extra 10 fields in the database.

[TT_Mark]

As Andy said the amount of serialize(), unserialize() would be worse than just storing them in separate fields. Surely normalising databases correctly helps to 'cut-down' the database?

Although saying that, I remember the Football Manager game used to (or maybe even still does) store all its data in serial text files.

[Andy]

Ok, the reason behind me thinking about it was I'd heard a few people saying that it's better that way when there are a lot of settings for each reader, having 10 values in an array instead of an extra 10 fields in the database.

Who said that?

Oh and by the way, they are wrong.

Although saying that, I remember the Football Manager game used to (or maybe even still does) store all its data in serial text files.

Well, a computer game does not even compare to a website as it does not get hundred of hits per second and therefore won't be in any risk of a deadlock.

[Tarvalon]

Ok, the reason behind me thinking about it was I'd heard a few people saying that it's better that way when there are a lot of settings for each reader, having 10 values in an array instead of an extra 10 fields in the database.

Oh and by the way, they are wrong.

Of course they are wrong, why would you take step 1 without taking step 2? Obviously the best way to handle this is to simply get rid of records altogether and store everything in a single excel spreadsheet inside of cell A1. You have three people filling out name, e-mail and address:

[Cell A1]
Name, Email, Address, Name, Email, Address, Name, Email, Address
[/Cell A1]

Now all you have to do is parse through ONE CELL! How could things get any more streamlined? And you obviously no longer need a DB as Excel can handle tens of thousands of cells, so with just one your site will be crazy fast!

</sarcasm>

[TT_Mark]

Although saying that, I remember the Football Manager game used to (or maybe even still does) store all its data in serial text files.

Well, a computer game does not even compare to a website as it does not get hundred of hits per second and therefore won't be in any risk of a deadlock.

Actually, the online version probably does

[jock]

I'm guilty of storing serialized arrays and sometimes even objects in database tables, sometimes JSON too! If possible you should avoid it!