Допустим в качестве значений какого-то столбца нужно сохранить массив чисел.
Правильный "реляционный" путь — завести еще одну таблицу, у которой будет два столбца — ключ первой таблицы и одно из чисел массива.
Тупой путь для ленивых — если массив имеет фиксированную длину (скажем 3..4 элемента) то можно просто завести 3..4 столбца с именами типа item1, item2, item3, item4 и хранить эти числа там.
Но на самом деле: а почему нельзя хранить непосредственно массивы?
Строки — это массивы символов, и их можно хранить в MySQL. Причем как строки фиксированной длины, так и переменной. Для строк действуют специальные операторы, например LIKE. Мы же не заводим отдельно таблицу символов строки и не храним каждый символ отдельно? И дело не только в производительности, но и в логике. Иногда массив это не часть реляционной схемы, а "нечто целое и неделимое" — примерно как строка, и размазывать его по строкам другой таблицы нежелательно.
Понятно что есть блобы, а начиная с MySQL 5.7 есть тип столбца JSON, позволяющий сохранять структурированные деревья в формате JSON. Но JSON это достаточно навороченная структура данных... а все-же почему просто массивов нет (а заодно и структур)? Это ведь именно программисту по идее решать, что делать частью реляционной модели а что нет. А получается что СУБД принуждает к тому чтобы делать частью реляционной модели все до самого низкого уровня.
Здравствуйте, x-code, Вы писали:
XC>Понятно что есть блобы, а начиная с MySQL 5.7 есть тип столбца JSON, позволяющий сохранять структурированные деревья в формате JSON. Но JSON это достаточно навороченная структура данных... а все-же почему просто массивов нет (а заодно и структур)? Это ведь именно программисту по идее решать, что делать частью реляционной модели а что нет. А получается что СУБД принуждает к тому чтобы делать частью реляционной модели все до самого низкого уровня.
Почему в MySQL ничего нет, почему оно есть в Постгресе, почему люди пользуются мысклем, а также главный вопрос жизни, вселенной и всего такого.
Здравствуйте, x-code, Вы писали:
XC>Понятно что есть блобы, а начиная с MySQL 5.7 есть тип столбца JSON, позволяющий сохранять структурированные деревья в формате JSON. Но JSON это достаточно навороченная структура данных... а все-же почему просто массивов нет (а заодно и структур)? Это ведь именно программисту по идее решать, что делать частью реляционной модели а что нет. А получается что СУБД принуждает к тому чтобы делать частью реляционной модели все до самого низкого уровня.
Чем тебе JSON не массив (а заодно и структура)?
P.S. Если хочешь дельный совет, а не просто пожаловаться, опиши свою конкретную ситуацию. Что у тебя за массивы, какого размера, что за данные в них, какие операции наз ними выполняются.
Здравствуйте, x-code, Вы писали:
XC>Допустим в качестве значений какого-то столбца нужно сохранить массив чисел. XC>Правильный "реляционный" путь — завести еще одну таблицу, у которой будет два столбца — ключ первой таблицы и одно из чисел массива.
Только так.
XC>Тупой путь для ленивых — если массив имеет фиксированную длину (скажем 3..4 элемента) то можно просто завести 3..4 столбца с именами типа item1, item2, item3, item4 и хранить эти числа там. XC>Но на самом деле: а почему нельзя хранить непосредственно массивы?
потому что ты такие данные обрабатывать не сможешь на SQL.
Нет там операций с массивами. В некоторых других СУБД такие операции имеются, и ограниченно можно работать с такими данными.
А просто хранить (записывать, читать и выдавать) -- пожалуйста.
Здравствуйте, x-code, Вы писали:
XC>Тупой путь для ленивых — если массив имеет фиксированную длину (скажем 3..4 элемента) то можно просто завести 3..4 столбца с именами типа item1, item2, item3, item4 и хранить эти числа там.
[крик души]
Ето путь идиотов, а не ленивых.
Видел такое на одном проекте. x полей, значения могут быть произвольные( множество значений больше x), а как потом ето обрабатывать — не подумали...
