json column vs multiple columns

Question

ni siquiera sé si llamarlo serialized column es correcto, pero me voy a explicar, por ejemplo, tengo una tabla para los usuarios, quiero almacenar el teléfono de los usuarios números (teléfono celular, hogar, oficina, etc.), entonces, estaba pensando en hacer una columna para cada tipo de número, pero al mismo tiempo me vino a la cabeza una idea, ¿qué pasa si guardo una cadena json en una sola columna, por lo tanto, nunca tendré una columna que probablemente nunca se utilizará y puedo convertir esa cadena en una matriz php cuando lea los datos de la base de datos, pero me gustaría escuchar las cosas buenas y malas de esta práctica, tal vez sea solo una mala idea, pero primero quiero saber lo que otras personas tienen que decir sobre

gracias

Answer 1

Respuesta corta, Varias columnas.

Respuesta larga:

Por el amor de todo lo sagrado en el mundo por favor no almacenar mutiple conjuntos de datos en una columna de texto único

Estoy suponiendo que tendrá una mesa que, o bien se

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

en primer lugar he de decir que tanto estas soluciones no son la mejor solución, pero si tuviera que escoger el de los dos: el primero es mejor. Hay un par de razones principalmente, aunque la capacidad de modificar y consultar específicamente es realmente importante. Piensa en algrothim para modificar la segunda opción.

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 

Esta solución tiene un total de 2 consultas y un algoritmo de búsqueda y reemplazo. ¡No es bueno!

Ahora piense en la primera solución.

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` = ? 

Esto es claramente mejor, pero no es mejor

Hay una tercera solución Digamos que usted quiere que un usuario sea capaz de insertar un número infinito de números de teléfono.

Permite utilizar una tabla de relaciones para eso, así que ahora tiene dos tablas.

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

ya se puede consultar todos los números de teléfono de un usuario con algo como esto

Ahora se puede consultar la tabla a través de una unión

Seleccionar usuarios. , teléfono. FROM Phone, Users WHERE phone.user_name =? AND Users.U_name =?

Los insertos son igual de fáciles y también es fácil verificar los tipos.

recuerda que esto es un ejemplo sencillo pero muy SQL proporciona una tonelada de energía a su estructura de datos que se debe utilizar en lugar de evitar que

Answer 2

Solo haría esto con datos no esenciales, por ejemplo, el color favorito del usuario, el tipo de marsupial favorito (obviamente 'no esencial' es para que usted decida). El problema al hacer esto para datos esenciales (número de teléfono, nombre de usuario, correo electrónico, nombre, apellido, etc.) es que se limita a lo que puede lograr con la base de datos. Estos incluyen campos de indexación, usando cláusulas ORDER BY, o incluso la búsqueda de una pieza específica de datos. Si más adelante te das cuenta de que necesitas realizar alguna de estas tareas, será un gran dolor de cabeza.

Lo mejor en esta situación es utilizar una tabla relacional para 1 a muchos objetos - ex UserPhoneNumbers. Tendría 3 columnas: user_id, phone_number y type. El user_id le permite vincular las filas de esta tabla con la fila de la tabla User, el phone_number es autoexplicativo, y el type podría ser 'home', 'cell', 'office', etc. Esto le permite seguir realizando las tareas que mencionado anteriormente, y también tiene el beneficio adicional de no perder espacio en columnas vacías, ya que solo agrega filas a esta tabla cuando lo necesite.

No sé cómo usted está familiarizado con MySQL, pero si usted no ha oído hablar de la normalización de bases de datos y combinaciones de consulta, ahora es un buen momento para comenzar a leer sobre ellos :)

Espero que esto ayude .

Answer 3

No estoy seguro de cuáles serían las ventajas de este enfoque. Usted dice "así que nunca tendré una columna que probablemente nunca se utilizará ..." Lo que creo que quiso decir fue (en su sistema) que a veces un usuario puede no tener un valor para cada tipo de número de teléfono disponible, y Siendo ese el caso, ¿por qué almacenar registros con columnas vacías?

Almacenar registros con algunas columnas vacías no es necesariamente malo. Sin embargo, si quiere normalizar su base de datos, puede tener una tabla separada para user_phonenumber y crear una relación 1: muchos entre los registros user y . La tabla user_phonenumber sería básicamente tiene cuatro columnas:

• id (clave principal)
• identificador de usuario (clave externa a la tabla de usuario)
• tipo (por ejemplo, teléfono móvil, hogar, oficina, etc.)
• valor (el número de teléfono)

Las restricciones serían que id es una clave principal, userid es una clave externa para user.id y type sería una enumeración (de todos los tipos de números de teléfono posibles).

Answer 4

Si trabaja con JSON, hay formas más elegante que MySQL. Recomendaría utilizar otra base de datos que funcione mejor con json, como mongoDB o un contenedor para SQL como Persevere, http://www.persvr.org/Documentation (ver "Perstore")