into - ¿Cómo almacenar arrays en MySQL?
return json mysql (7)
En MySQL, use el tipo JSON.
Contra las respuestas anteriores, el estándar SQL ha incluido tipos de arreglos durante casi veinte años; Son útiles, incluso si MySQL no los ha implementado.
Sin embargo, en su ejemplo, probablemente querrá crear tres tablas: persona y fruta, luego persona_fruta para unirse a ellas.
DROP TABLE IF EXISTS person_fruit;
DROP TABLE IF EXISTS person;
DROP TABLE IF EXISTS fruit;
CREATE TABLE person (
person_id INT NOT NULL AUTO_INCREMENT,
person_name VARCHAR(1000) NOT NULL,
PRIMARY KEY (person_id)
);
CREATE TABLE fruit (
fruit_id INT NOT NULL AUTO_INCREMENT,
fruit_name VARCHAR(1000) NOT NULL,
fruit_color VARCHAR(1000) NOT NULL,
fruit_price INT NOT NULL,
PRIMARY KEY (fruit_id)
);
CREATE TABLE person_fruit (
pf_id INT NOT NULL AUTO_INCREMENT,
pf_person INT NOT NULL,
pf_fruit INT NOT NULL,
PRIMARY KEY (pf_id),
FOREIGN KEY (pf_person) REFERENCES person (person_id),
FOREIGN KEY (pf_fruit) REFERENCES fruit (fruit_id)
);
INSERT INTO person (person_name)
VALUES
(''John''),
(''Mary''),
(''John''); -- again
INSERT INTO fruit (fruit_name, fruit_color, fruit_price)
VALUES
(''apple'', ''red'', 1),
(''orange'', ''orange'', 2),
(''pineapple'', ''yellow'', 3);
INSERT INTO person_fruit (pf_person, pf_fruit)
VALUES
(1, 1),
(1, 2),
(2, 2),
(2, 3),
(3, 1),
(3, 2),
(3, 3);
Si desea asociar a la persona con una variedad de frutas, puede hacerlo con una vista:
DROP VIEW IF EXISTS person_fruit_summary;
CREATE VIEW person_fruit_summary AS
SELECT
person_id AS pfs_person_id,
max(person_name) AS pfs_person_name,
cast(concat(''['', group_concat(json_quote(fruit_name) ORDER BY fruit_name SEPARATOR '',''), '']'') as json) AS pfs_fruit_name_array
FROM
person
INNER JOIN person_fruit
ON person.person_id = person_fruit.pf_person
INNER JOIN fruit
ON person_fruit.pf_fruit = fruit.fruit_id
GROUP BY
person_id;
La vista muestra los siguientes datos:
+---------------+-----------------+----------------------------------+
| pfs_person_id | pfs_person_name | pfs_fruit_name_array |
+---------------+-----------------+----------------------------------+
| 1 | John | ["apple", "orange"] |
| 2 | Mary | ["orange", "pineapple"] |
| 3 | John | ["apple", "orange", "pineapple"] |
+---------------+-----------------+----------------------------------+
En 5.7.22, querrá usar JSON_ARRAYAGG , en lugar de hackear la matriz a partir de una cadena.
Tengo dos tablas en MySQL. La persona de la tabla tiene las columnas siguientes:
id | name | fruits
La columna de fruits puede contener nula o una serie de cadenas como (''apple'', ''orange'', ''banana'') o (''strawberry''), etc. La segunda tabla es Table Fruit y tiene las siguientes tres columnas:
____________________________
fruit_name | color | price
____________________________
apple | red | 2
____________________________
orange | orange | 3
____________________________
...,...
Entonces, ¿cómo debo diseñar la columna de fruits en la primera tabla para que pueda contener una serie de cadenas que toman valores de la columna fruit_name en la segunda tabla? Como no hay ningún tipo de datos de matriz en MySQL, ¿cómo debo hacerlo?
La forma correcta de hacer esto es usar varias tablas y JOIN ellas 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`)
);
La tabla person_fruit contiene una fila para cada fruta con la que una persona está asociada y efectivamente vincula las tablas person y fruits , IE
1 | "banana"
1 | "apple"
1 | "orange"
2 | "straberry"
2 | "banana"
2 | "apple"
Cuando quieres recuperar a una persona y toda su fruta, puedes 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 lo necesitan. Las bases de datos relacionales (SQL es exactamente eso) funcionan utilizando 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 puedes pensar "Me gustaría una lista de cosas aquí", en lugar de hacer una nueva tabla, vincula la fila en una tabla con la fila en otra tabla. [1] De esa manera, puedes representar relaciones M: N. Otra ventaja es que esos enlaces no saturarán la fila que contiene el elemento vinculado. Y la base de datos puede indexar esas filas. Las matrices normalmente no están indexadas.
Si no necesita bases de datos relacionales, puede utilizar, por ejemplo, un almacén de valores clave.
Lea acerca de la normalización de la base de datos , por favor. La regla de oro es "[Cada] no-clave [atributo] debe proporcionar un hecho sobre la clave, toda la clave, y nada más que la clave". Una matriz hace demasiado. Tiene múltiples hechos y almacena el pedido (que no está relacionado con la relación en sí). Y el rendimiento es pobre (ver arriba).
Imagina que tienes una mesa de personas y 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 una matriz para cada cosa con la que está conectado? No, eso no es un atributo de la persona misma.
[1]: ¡Está bien si la tabla de enlace solo tiene dos columnas (las claves principales de cada tabla)! Sin embargo, si la relación en sí tiene atributos adicionales, deben representarse 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, los rrays 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 / arrays en MySQL al crear una tabla que los describe y agregar cada valor como su propio registro. La tabla puede tener solo 2 o 3 columnas, o puede contener muchas más. Cómo almacenar este tipo de datos realmente depende de las características de los datos.
Por ejemplo, ¿la lista contiene un número estático o 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 de Key: Value / Document, como Cassandra, MongoDB, Redis, etc. también ofrecen una buena solución. Solo tenga en cuenta dónde se almacenan realmente los datos (si están almacenados 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 puede tener motivos para almacenarlo en otro lugar, o puede usar una clave en la memoria: la base de datos de valores como caché para los datos almacenados en el disco en algún lugar o como un almacenamiento efímero Para cosas como sesiones.
Una nota a tener en cuenta, puede almacenar matrices en Postgres.
Utilice el tipo de campo de base de datos BLOB para almacenar matrices.
Ref: http://us.php.net/manual/en/function.serialize.php
Valores de retorno
Devuelve una cadena que contiene una representación de valor de byte-stream que se puede almacenar en cualquier lugar.
Tenga en cuenta que esta es una cadena binaria que puede incluir bytes nulos, y debe almacenarse y manejarse como tal. Por ejemplo, la salida serialize () generalmente se debe almacenar en un campo BLOB en una base de datos, en lugar de un campo CHAR o TEXT.
puedes almacenar tu array usando group_Concat así
INSERT into Table1 (fruits) (SELECT GROUP_CONCAT(fruit_name) from table2)
WHERE ..... //your clause here
AQUÍ un ejemplo en violín.