Después de de esta larga selección de información dimos con la respuesta este rompecabezas que presentan algunos de nuestros lectores. Te dejamos la respuesta y nuestro objetivo es serte de mucha apoyo.
Solución:
La forma correcta de hacer esto es usar varias tablas y JOIN ellos en sus consultas.
Por ejemplo:
CREATE TABLE person (
`id` INT NOT NULL PRIMARY KEY,
`name` VARCHAR(50)
);
CREATE TABLE fruits (
`fruit_name` VARCHAR(20) NOT NULL PRIMARY KEY,
`color` VARCHAR(20),
`price` INT
);
CREATE TABLE person_fruit (
`person_id` INT NOT NULL,
`fruit_name` VARCHAR(20) NOT NULL,
PRIMARY KEY(`person_id`, `fruit_name`)
);
El person_fruit La tabla contiene una fila para cada fruta con la que una persona está asociada y vincula efectivamente la person y fruits mesas juntas, IE
1 | "banana"
1 | "apple"
1 | "orange"
2 | "straberry"
2 | "banana"
2 | "apple"
Cuando desee recuperar a una persona y toda su fruta, puede hacer algo como esto:
SELECT p.*, f.*
FROM person p
INNER JOIN person_fruit pf
ON pf.person_id = p.id
INNER JOIN fruits f
ON f.fruit_name = pf.fruit_name
La razón por la que no hay matrices en SQL es porque la mayoría de las personas realmente no las necesitan. Las bases de datos relacionales (SQL es exactamente eso) funcionan usando relaciones, y la mayoría de las veces, es mejor si asigna una fila de una tabla a cada “bit de información”. Por ejemplo, donde puede pensar “Me gustaría una lista de cosas aquí”, cree una nueva tabla, vinculando la fila en una tabla con la fila en otra tabla.[1] De esa manera, puede representar relaciones M:N. Otra ventaja es que esos enlaces no abarrotarán la fila que contiene el elemento enlazado. Y la base de datos puede indexar esas filas. Las matrices normalmente no están indexadas.
Si no necesita bases de datos relacionales, puede usar, por ejemplo, un key-almacén de valor.
Lea acerca de la normalización de la base de datos, por favor. La regla de oro es “[Every] no-key [attribute] debe proporcionar un hecho acerca de la key, El conjunto key, y nada más que el key.”. Un array hace demasiado Tiene múltiples hechos y almacena el orden (que no está relacionado con la relación en sí). Y el rendimiento es pobre (ver arriba).
Imagine que tiene una mesa de personas y tiene una mesa con llamadas telefónicas de personas. Ahora puede hacer que cada fila de personas tenga una lista de sus llamadas telefónicas. Pero cada persona tiene muchas otras relaciones con muchas otras cosas. ¿Significa eso que mi tabla de persona debe contener un array por cada cosa con la que está conectado? No, eso no es un attribute de la persona misma.
[1]: Está bien si la tabla de enlace solo tiene dos columnas (la principal keys de cada mesa)! Si la relación en sí tiene más attributes sin embargo, deben estar representados en esta tabla como columnas.
MySQL 5.7 ahora proporciona un tipo de datos JSON. Este nuevo tipo de datos proporciona una nueva forma conveniente de almacenar datos complejos: listas, diccionarios, etc.
Dicho esto, las matrices no mapean bien las bases de datos, por lo que los mapas relacionales de objetos pueden ser bastante complejos. Históricamente, las personas han almacenado listas/matrices en MySQL creando una tabla que las describe y agregando cada valor como su propio registro. La tabla puede tener solo 2 o 3 columnas, o puede contener muchas más. La forma en que almacena este tipo de datos realmente depende de las características de los datos.
Por ejemplo, ¿la lista contiene un static o número dinámico de entradas? ¿La lista seguirá siendo pequeña o se espera que crezca a millones de registros? ¿Habrá muchas lecturas en esta tabla? ¿Muchas escrituras? ¿Muchas actualizaciones? Todos estos son factores que deben tenerse en cuenta al decidir cómo almacenar colecciones de datos.
Además, los almacenes de datos clave/valor, los almacenes de documentos como Cassandra, MongoDB, Redis, etc. también brindan una buena solución. Solo tenga en cuenta dónde se almacenan realmente los datos (si se almacenan en el disco o en la memoria). No todos sus datos necesitan estar en la misma base de datos. Algunos datos no se asignan bien a una base de datos relacional y es posible que tenga motivos para almacenarlos en otro lugar, o es posible que desee utilizar una base de datos en memoria. key:value base de datos como un caché activo para datos almacenados en disco en algún lugar o como un almacenamiento efímero para cosas como sesiones.
Nos puedes defender nuestra investigación fijando un comentario y dejando una puntuación te damos la bienvenida.