Хранение csv в поле MySQL - плохая идея?

Question

У меня есть две таблицы, одна таблица пользователей и таблица элементов. В таблице пользователя есть поле «items». Таблица «items» состоит только из уникального id и item_name.

Теперь каждый пользователь может иметь несколько элементов. Я хотел бы избежать создания третьей таблицы, которая будет связывать элементы с пользователем, а скорее имеет поле в user_table, в котором хранятся идентификаторы элементов, подключенные к пользователю в поле «csv».

Таким образом, у любого данного пользователя есть поле «предметы», которое может иметь значение «32,3,98,56».

Возможно, стоит упомянуть, что максимальное количество элементов на пользователя ограничено (< 5).

Вопрос: Является ли этот подход вообще плохой идеей по сравнению с наличием третьей таблицы, содержащей пары user-> item?

Не третья таблица создала бы довольно накладные расходы, когда вы захотите найти все элементы пользователя (мне пришлось бы перебирать все элементы, возвращаемые MySQL отдельно).

Answer 1

Вы не хотите хранить значение в форме, разделенной запятой.

Рассмотрите случай, когда вы решите присоединиться к этой колонке с другой таблицей.

Рассмотрим у вас есть,

x items 
1 1, 2, 3 
1 1, 4 
2 1 

и вы хотите, чтобы найти различные значения для каждого х е:

x items 
1 1, 2, 3, 4 
2 1 

или может быть хотите, чтобы проверить, если он имеет 3 в нем

или могут захотеть преобразовать их в отдельные строки:

x items 
1 1 
1 2 
1 3 
1 1 
1 4 
2 1 

Это будет ОГРОМНАЯ БОЛЬ.

Использование по крайней мере нормализации 1-й принцип - иметь отдельную строку для каждого значения.

Теперь, скажем, изначально у вас это, как вы таблицы:

x item 
1 1 
1 2 
1 3 
1 1 
1 4 
2 1 

Вы можете легко преобразовать его в значения CSV:

select x, group_concat(item order by item) items 
from t 
group by x 

Если вы хотите найти, если х = 1 имеет пункт 3 . Легко.

select * from t where x = 1 and item = 3 

, который в предыдущем случае использования будет ужасноfind_in_set:

select * from t where x = 1 and find_in_set(3, items); 

Если вы думаете, что вы можете использовать как со значениями CSV для поиска, то первый like %x% не может использовать индексы. Во-вторых, это приведет к неправильным результатам.
Скажите, что вы хотите проверить, присутствует ли элемент ab, и вы делаете %ab%, он вернет строки с abc abcd abcde .....

Если у вас много пользователей и элементов, то я предложил бы создать отдельную таблицу users с идентификатором пользователя ПК, другой items с ПК Itemid и, наконец, отображение таблицы user_item, имеющий идентификатор, ItemId столбцы.

Если вы знаете, что вам просто нужно будет хранить и извлекать эти значения, а не выполнять какие-либо операции с ним, такие как объединение, поиск, различие, преобразование в отдельные строки и т. Д. И т. Д. - возможно, может быть, вы можете (Я все равно не буду).

Answer 2

Хранение сложных данных непосредственно в реляционной базе данных является нестандартным использованием реляционной базы данных. Обычно они предназначены для нормализованных данных.

Существуют расширения, которые различаются в зависимости от марки программного обеспечения, которая может помочь. Или вы можете нормализовать свой CSV-файл в правильно спроектированные таблицы. Это зависит от множества вещей. В этом случае поговорите с вашим архитектором корпоративных данных.

Является ли это плохая идея, зависит от ваших потребностей бизнеса. Я не могу оценить ваши потребности в бизнесе из пути здесь, в Интернете. В этом случае поговорите с менеджером по продуктам.