Может ли кто-нибудь сказать мне, какой метод вызывается, когда вы храните поля и значения, разделенные в базе данных, например, через запятую. Я видел, как его использовали, но не знал, как это называется.
id | options
1 | option1=this, option2=that, option3=other
2 | option1=this, option2=that, option3=other
3 | option1=this, option2=that
это называется список пар атрибут-значение, разделенных запятыми, и это совершенно правильно ...
...в редкие и исключительные обстоятельства!
Я с Полом; «Глупый» - первое слово, которое приходит мне в голову.
Кстати, причина, по которой это «глупо», «глупо» или «действительно плохая идея», заключается в том, что это лучше сделать в виде отдельной таблицы с полем внешнего ключа, указывающим обратно на поле id в первой таблице, «ключ» поле и поле значения. это позволяет индивидуально индексировать пары ключ / значение, искать и манипулировать ими (добавлять, удалять, обновлять).
и даже тогда это полезно только в некоторых случаях - когда существует переменное количество неизвестных / произвольных ключей, которые данная запись могла бы связать с собой. если имя и количество ключей известны заранее, есть способы лучше справиться с этим.
В википедии есть несколько хороших вводных статей по базам данных и нормализации баз данных, которые стоит прочитать. начать с Модели баз данных и Нормализация базы данных
Согласно паре книг на моей полке, вы ищете такой термин:
Хотя из каждого правила есть исключения, составные поля редко необходимо.
Составные поля могут нанести ущерб целостности данных, и их следует избегать. Проблемы чаще всего возникают, когда вы пытаетесь отредактировать, удалить или отсортировать дату в составном поле.
Когда вы «нормализуете» свою базу данных и гарантируете, что в каждом поле хранится только одно значение, вы оказываете себе (и другим) огромную услугу в будущем, помогая гарантировать целостность данных и точную информацию.
Я называю это нарушение первой нормальной формы.
Я согласен это глупо
ЕСЛИ
это модель данных вашего приложения.
На самом деле это очень полезно, если вы просто сохраняете то, что было проанализировано в другом месте, например параметры пользователя в клиентском приложении. Заставляет клиента работать по разбору. Это тривиальный механизм хранения, который можно легко разделить и сохранить в коллекции на стороне клиента.
В общем, это «повторяющееся значение» и нарушает (как минимум) Первую нормальную форму (вроде): http://en.wikipedia.org/wiki/Database_normalization
Значения, разделенные запятыми, близки.
Я не уверен, почему вы должны повторять имена полей для каждого значения.
Вы можете использовать типы массивов в PostgreSQL для достижения чего-то похожего на то, что вам нужно, но это все еще действительно плохая идея (tm).
Я бы предпочел сделать это именно так, если вы будете делать что-нибудь с этими данными, кроме простого их сохранения.
id | opt | content
1 | 1 | this
1 | 2 | that
1 | 3 | other
2 | 1 | this
2 | 2 | that
2 | 3 | other
3 | 1 | this
3 | 2 | that
3 | 3 | other