json column vs multiple columns

Question

i don't even know if calling it serialized column is right, but i'm going to explain myself, for example, i have a table for users, i want to store the users phone numbers(cellphone, home, office, etc), so, i was thinkin' to make a column for each number type, but at the same time came to my head an idea, what if i save a json string in a single column, so, i will never have a column that probably will never be used and i can turn that string into a php array when reading the data from database, but i would like to hear the goods and bads of this practice, maybe it is just a bad idea, but first i want to know what other people have to say about

thanks

Answer 1

Short Answer, Multiple columns.

Long Answer:

For the love of all that is holy in the world please do not store mutiple data sets in a single text column

I am assuming you will have a table that will either be

+------------------------------+      +----------------------+
| User |  cell | office | home |  OR  | User | JSON String   |
+------------------------------+      +----------------------+

First I will say both these solutions are not the best solution but if you were to pick the from the two the first is best. There are a couple reasons mainly though the ability to modify and query specifically is really important. Think about the algrothim to modify the second option.

SELECT `JSON` FROM `table` WHERE `User` = ?

Then you have to do a search and replace in either your server side or client side language

Finally you have to reinsert the JSON string

This solution totals 2 queries and a search and replace algorithm. No Good!

Now think about the first solution.

SELECT * FROM `table` WHERE `User` = ?

Then you can do a simple JSON encode to send it down

To modify you only need one Query.

UPDATE `table` SET `cell` = ? WHERE `User` = ?

to update more than one its again a simple single query 

UPDATE `table` SET `cell` = ?, `home` = ? WHERE `User` = ?

This is clearly better but it is not best

There is a third solution Say you want a user to be able to insert an infinite number of phone numbers.

Lets use a relation table for that so now you have two tables.

              +-------------------------------------+
+---------+   |      Phone                          | 
| Users   |   +-------------------------------------+ 
+---------+   | user_name| phone_number | type      |
| U_name  |   +-------------------------------------+
+---------+

Now you can query all the phone numbers of a user with something like this

Now you can query the table via a join

SELECT Users. , phone. FROM Phone, Users WHERE phone.user_name = ? AND Users.U_name = ?

Inserts are just as easy and type checking is easy too.

Remember this is a simple example but SQL really provides a ton of power to your data-structure you should use it rather than avoiding it

Answer 2

If you work with json, there are more elegant ways than MySQL. Would recommend to use either another Database working better with json, like mongoDB or a wrapper for SQL like Persevere, http://www.persvr.org/Documentation (see "Perstore")

Answer 3

I would only do this with non-essential data, for example, the user's favorite color, favorite type of marsupial (obviously 'non-essential' is for you to decide). The problem with doing this for essential data (phone number, username, email, first name, last name, etc) is that you limit yourself to what you can accomplish with the database. These include indexing fields, using ORDER BY clauses, or even searching for a specific piece of data. If later on you realize you need to perform any of these tasks it's going to be a major headache.

Your best best in this situation is using a relational table for 1 to many objects - ex UserPhoneNumbers . It would have 3 columns: user_id , phone_number , and type . The user_id lets you link the rows in this table to the appropriate User table row, the phone_number is self explanatory, and the type could be 'home', 'cell', 'office', etc. This lets you still perform the tasks I mentioned above, and it also has the added benefit of not wasting space on empty columns, as you only add rows to this table as you need to.

I don't know how familiar you are with MySQL, but if you haven't heard of database normalization and query JOINs, now is a good time to start reading up on them :)

Hope this helps.

Answer 4

I'm not sure what the advantages of this approach would be. You say "so, i will never have a column that probably will never be used..." What I think you meant was (in your system) that sometimes a user may not have a value for each type of phone number available, and that being the case, why store records with empty columns?

Storing records with some empty columns is not necessarily bad. However, if you wanted to normalize your database, you could have a separate table for user_phonenumber , and create a 1:many relationship between user and user_phonenumber records. The user_phonenumber table would basically have four columns:

• id (primary key)
• userid (foreign key to user table)
• type (eg cellphone, home, office, etc.)
• value (the phone number)

Constraints would be that id is a primary key, userid is a foreign key for user.id, and type would be an enum (of all possible phone number types).