Как хранить массивы в MySQL?

У меня есть две таблицы в MySQL. В таблице Person есть следующие столбцы:

id | name | fruits

fruitsСтолбец может содержать нуль или массив строк типа ( «яблоко», «апельсин», «бананового»), или ( «клубника») и т.д. вторая таблица Таблица фруктов и имеет следующие три столбца:

____________________________
fruit_name | color  | price
____________________________
apple      | red    | 2
____________________________
orange     | orange | 3
____________________________
...,...

Итак, как мне разработать fruits столбец в первой таблице, чтобы он мог содержать массив строк, принимающих значения из fruit_nameстолбца во второй таблице? Поскольку в MySQL нет типа данных массива, как мне это сделать?

Правильный способ сделать это - использовать несколько таблиц и JOINих в ваших запросах.

Например:

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`)
);

person_fruitТаблица содержит одну строку для каждого плода человека , связанного с и эффективно связывает personи fruitsтаблицы вместе, т.е.

1 | "banana"
1 | "apple"
1 | "orange"
2 | "straberry"
2 | "banana"
2 | "apple"

Если вы хотите вернуть человека и все его плоды, вы можете сделать что-то вроде этого:

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

Причина того, что в SQL нет массивов, заключается в том, что большинству людей он действительно не нужен. Реляционные базы данных (как раз и является SQL) работают с использованием отношений, и в большинстве случаев лучше, если вы назначите одну строку таблицы каждому «биту информации». Например, если вы думаете: «Мне нужен здесь список вещей», вместо этого создайте новую таблицу, связав строку в одной таблице со строкой в ​​другой таблице. [1] Таким образом, вы можете представить отношения M: N. Еще одно преимущество состоит в том, что эти ссылки не загромождают строку, содержащую связанный элемент. И база данных может индексировать эти строки. Массивы обычно не индексируются.

Если вам не нужны реляционные базы данных, вы можете использовать, например, хранилище ключей и значений.

Прочтите о нормализации базы данных , пожалуйста, . Золотое правило гласит: «[Каждый] неключевой [атрибут] должен предоставлять факт о ключе, весь ключ и ничего, кроме ключа». Массив делает слишком много. Он содержит несколько фактов и хранит порядок (который не связан с самим отношением). И производительность оставляет желать лучшего (см. Выше).

Представьте, что у вас есть стол с людьми, и у вас есть стол, за которым звонят люди. Теперь вы можете создать для каждой строки человека список его телефонных звонков. Но у каждого человека много других отношений ко многому другому. Означает ли это, что моя личная таблица должна содержать массив для каждой отдельной вещи, к которой он подключен? Нет, это не атрибут самого человека.

[1]: Ничего страшного, если таблица связывания имеет только два столбца (первичные ключи из каждой таблицы)! Если у самой связи есть дополнительные атрибуты, они должны быть представлены в этой таблице в виде столбцов.

MySQL 5.7 теперь предоставляет тип данных JSON . Этот новый тип данных обеспечивает удобный новый способ хранения сложных данных: списков, словарей и т. Д.

Тем не менее, rrays плохо отображают базы данных, поэтому объектно-реляционные карты могут быть довольно сложными. Исторически люди сохраняли списки / массивы в MySQL, создавая таблицу, которая их описывает, и добавляя каждое значение как свою собственную запись. В таблице может быть только 2 или 3 столбца, а может быть и больше. То, как вы храните этот тип данных, действительно зависит от характеристик данных.

Например, содержит ли список статическое или динамическое количество записей? Останется ли список небольшим или ожидается, что он вырастет до миллионов записей? Будет ли много чтений по этой таблице? Много пишет? Много обновлений? Это все факторы, которые необходимо учитывать при принятии решения о том, как хранить коллекции данных.

Кроме того, хранилища данных Key: Value / хранилища документов, такие как Cassandra, MongoDB, Redis и т. Д., Также являются хорошим решением. Просто помните, где на самом деле хранятся данные (если они хранятся на диске или в памяти). Не все ваши данные должны находиться в одной базе данных. Некоторые данные плохо отображаются в реляционной базе данных, и у вас могут быть причины для их хранения в другом месте, или вы можете использовать базу данных ключ: значение в памяти в качестве горячего кеша для данных, хранящихся где-то на диске, или в качестве временного хранилища для таких вещей, как сеансы.

Следует учесть, что вы можете хранить массивы в Postgres.

В MySQL используйте тип JSON.

Вопреки приведенным выше ответам, стандарт SQL уже почти двадцать лет включает типы массивов; они полезны, даже если MySQL не реализовал их.

Однако в вашем примере вы, вероятно, захотите создать три таблицы: person и fruit, а затем person_fruit, чтобы присоединиться к ним.

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);

Если вы хотите связать человека с множеством фруктов, вы можете сделать это с помощью представления:

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;

В представлении отображаются следующие данные:

+---------------+-----------------+----------------------------------+
| pfs_person_id | pfs_person_name | pfs_fruit_name_array             |
+---------------+-----------------+----------------------------------+
|             1 | John            | ["apple", "orange"]              |
|             2 | Mary            | ["orange", "pineapple"]          |
|             3 | John            | ["apple", "orange", "pineapple"] |
+---------------+-----------------+----------------------------------+

В 5.7.22 вы захотите использовать JSON_ARRAYAGG , а не взламывать массив из строки.

Используйте тип поля базы данных BLOB для хранения массивов.

Ссылка: http://us.php.net/manual/en/function.serialize.php

Возвращаемые значения

Возвращает строку, содержащую представление значения в потоке байтов, которое может быть сохранено где угодно.

Обратите внимание, что это двоичная строка, которая может включать нулевые байты и должна храниться и обрабатываться как таковая. Например, вывод serialize () обычно должен храниться в поле BLOB в базе данных, а не в поле CHAR или TEXT.

вы можете сохранить свой массив, используя group_Concat, например

 INSERT into Table1 (fruits)  (SELECT GROUP_CONCAT(fruit_name) from table2)
 WHERE ..... //your clause here

ЗДЕСЬ пример на скрипке