Как правильно хранить лист строк в базе данных?
Есть база данных — MySQL. В ней есть таблица. В одной из колонок мне нужно хранить список строк. Первое, что приходить на ум это сделать из моего листа строк одну строку через запятую и хранить её в базе как строку, а при получении из бд — сплитить по запятой, но такое ощущение, что это костыль. Может для этого есть более нормальные способы?
Отслеживать
задан 8 апр 2018 в 10:25
The Prototype The Prototype
641 4 4 серебряных знака 21 21 бронзовый знак
для каких целей храниться этот список. возможно ли редактирование какой то отдельной строки из списка, независимо от остальных. Реляционная модель предполагает, что заводится отдельная таблица, в которой хранятся строки по одной в записи с ссылкой на id сущности из основной таблицы. Но бывают случаи (довольно редкие), когда это излишне
8 апр 2018 в 11:08
В данном случае строки хранятся просто как данные, они не будут изменяться, разве что только добавляться, а так — просто будут выводится в textArea (javafx).
8 апр 2018 в 11:50
Если это тупо кусок текста, то тогда проще его так же одним куском и хранить. Смысл разделять есть когда вам надо например по запросу от клиента удалить именно 3ю строку не трогая остальные
Как можно хранить список id в одной строке в MySQL?
1. Как можно хранить этот список, что бы потом быстро и средствами MySQL получать из таблицы table1 список строк, указанных в таблице table2?
2. Можно ли хранить эти значения в строке в виде массива JSON, а затем в PHP получать этот массив и осуществлять выборку из table1 дополнительным запросом? Или в MySQL есть специальный тип для таких задач?
3. Можно ли вообще хранить информацию в базе данных MySQL в виде JSON? Как часто так делают?
- Вопрос задан более трёх лет назад
- 243 просмотра
1 комментарий
Простой 1 комментарий
Как хранить список в mysql
15 февраля 2015
Время от времени мне прилетают в почту занятные вопросы. Последний про хранение упорядоченного списка в базе данных.
Имеется возможность загрузки фото в альбомы. Нужно реализовать возможность упорядочивать фото в пределах альбома. Автор уже хранит порядок в поле order , но его напрягает, что при перетаскивании какой-либо из картинок нужно обновлять order у фотографий всего альбома.
Для начала, стоит оценить частоту изменений порядка фото. Если операция не очень частая и выполняется, например, только админом раз в день и в альбомах не очень много фото, можно смело хранить order как integer и обновлять, как автор и делает.
Если же операция достаточно частая, можно схитрить и хранить order как decimal . В этом случае при вставке или перемещении фото между двумя другими необходимо обновить только order непосредственно перемещаемой записи.
Если мы перемещаем фото C и засовываем его между фото A и фото B , то значение order для него вычисляется как
C.order = A.order + (B.order - A.order) / 2;
UPD: из за ограничений точности следует проверять, влезет ли в базу очередное значение. Если нет — пересчитывать order . Даже несмотря на то, что от пересчётов мы не избавились, их частота сократилась для худшего случая на порядок.
Комментарии RSS по email OK
MT 15 февр. 2015 г., 18:43:23
Как вариант, в случае использования целых весов элементов можно воспользоваться школьным BASIC’овским трюком — вес элементов инкрементировать десятками: 10, 20, 30 и т. д. Тогда пересчёт весов других элементов будет требоваться нечасто (только если «места» между конкретными двумя элементами не осталось), и даже если потребуется — то не обязательно всех.
oWeRQ 15 февр. 2015 г., 19:56:17
Стоит учитывать, что если order = id и между элементами нет пробелов, B.order — A.order == 1, а 1 очень плохо несколько раз делится пополам, даже decimal(n, 6) быстро закончится, чтобы потом не возиться с дробями можно использовать integer order = id * 1024(хватит на 10 перемещений «во внутрь»), временами пресчитывать order.
Sam 15 февр. 2015 г., 20:10:47
oWeRQ, хорошо подмечено. В decimal влезает, в случае того же MySQL, 13 знаков после запятой. То есть хватит на 13 делений. MT, это усложнит алгоритм, хотя и с decimal мы тоже рано или поздно упрёмся.
Структура таблиц БД: хранение списков значений наряду с обычными значениями
БД: MySQL.
Задача: хранить словаревидные данные в виде id:int->value:string.
Проблема: оказалось, что иногда нужно, чтобы одному id соответствовал список значений. При этом, если даже список состоит из одного элемента, все равно нужно отличать его от обычного значения.
Я вижу несколько вариантов решения, но ни один мне не нравится.
1) Хранить данные не в виде строки, а в каком-то формате: XML, JSON, etc. Тогда в одно строковое поле можно будет сохранить целый объект.
Вариант не нравится тем, что в итоге получаем денормализацию данных и проблемы, с ней связанные, например, невозможность оперировать значениями списка по отдельности стандартными средствами SQL. Чтение и изменение отдельных элементов прийдется реализовывать средствами приложения.
1.а) Хранить данные в одной строке с разделителем. Это частный случай варианта 1, и минусы те же самые.
2) Создать отдельную таблицу для значений списков.
Вариант не нравится тем, что прийдется делать запросы уже к двум таблицам как при чтении, так и при записи.
3) Хранить все данные в одной таблице, просто не делать id строки словаря уникальным ключом, тогда можно будет добавлять несколько записей для одного id.
Не нравится тем, что тогда сложно определить, является ли элемент обычным элементом, или же частью списка. Добавление специального поля-флага а-ля is_list_element — костыль.
- Вопрос задан более трёх лет назад
- 14107 просмотров