Зачем хранить данные в разных строках в базе данных?

Question

Зачем хранить данные в разных строках в базе данных?

0

Я заметил, что некоторые люди хранят связанные данные в разных строках в базе данных, а некоторые poeple помещают связанные данные в одну строку.

Например

  id  user_id  field_id  value
  1      1        9     "name 1"
  2      1       10     "address 1"
  3      1       11     "phone 1"
  4      2        9     "name 2"
  5      2       10     "address 2"
  6      2       11     "phone 2"

против

 id     user_id    name         address      phone
 1        1        name 1     address 1     phone 1
 2        2        name 2     address 2     phone 2

Здесь вы видите два способа хранения данных для пользователя 1 и пользователя 2. Я не знаю, почему первый метод будет использоваться во втором.

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

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

Спасибо

Paul Patt 21 фев. 2018, в 01:13

Источник

0

Вы имеете в виду столбцы? Если люди используют его первым способом, это плохая практика, он даже не проходит 1NF.
Spencer Wieczorek 20 фев. 2018, в 23:37
0

Wordpress использует первый метод для хранения материалов в базе данных, что превращает мою жизнь в настоящий ад. Чтобы сделать простую вещь, я должен потратить целый день, чтобы получить правильный SQL
Paul Patt 20 фев. 2018, в 23:43

Теги:

mysql

1 ответ

Ещё вопросы

Вы имеете в виду столбцы? Если люди используют его первым способом, это плохая практика, он даже не проходит 1NF.
Wordpress использует первый метод для хранения материалов в базе данных, что превращает мою жизнь в настоящий ад. Чтобы сделать простую вещь, я должен потратить целый день, чтобы получить правильный SQL

Evert · Answer 1 · 2018-02-20T21-11-00.000Z

2

Первый дизайн таблицы позволяет конечным пользователям динамически добавлять новые поля. Некоторое программное обеспечение может позволить вам добавлять новые поля к определенным вещам. Многие CMS делают это, а также такие приложения, как Jira. Предположительно, есть отдельная таблица fields где они могут быть определены.

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

Делайте это только для настраиваемых полей, но сохраняйте поля по умолчанию
Возможно, вместо этого используйте тип JSON и просто выгрузите все пользовательские данные. Это не так хорошо, как индексы таблицы значений key->.

Evert 20 фев. 2018, в 21:11

0

Спасибо за ваш ответ, но вы не объяснили, почему метод 2 следует избегать любой ценой, даже при том, что SQL-запросы кажутся проще, короче и быстрее при использовании метода 2.
Paul Patt 20 фев. 2018, в 23:38
1

@PaulPatt Они сказали, что метод 1 ( дизайн первой таблицы ) следует избегать любой ценой, а не метод два, что хорошо.
Spencer Wieczorek 20 фев. 2018, в 23:39
0

Хорошо, я согласен, метид 2 кажется лучше. Итак, почему популярная CMS, такая как WordPress, использует метод 1, где он делает SQL-запросы настолько сложными?
Paul Patt 20 фев. 2018, в 23:41
0

Я описал, почему они делают это ... чтобы пользователи могли динамически добавлять новые поля. Дайте мне знать, если это было неясно. Рад разработать.
Evert 20 фев. 2018, в 23:43
0

Ни один из методов не хорош. Я хотел бы отослать вас к обсуждению нормальных форм: en.wikipedia.org/wiki/Database_normalization . Он состоит из определения атомарности значения данных и последующей работы на основе того, существуют ли ограничения, такие как закрытое перечисление значений.
T Gray 20 фев. 2018, в 23:46
0

@TGray вместо того, чтобы предлагать читать теорию нормальных форм, возможно, вы можете указать конкретно, что не так с дизайном второй таблицы?
Evert 20 фев. 2018, в 23:47
0

Эверет, почему пользователи не могут добавлять новые поля динамически, используя метод секунд? Я считаю, что можно добавлять / удалять столбцы из таблицы.
Paul Patt 20 фев. 2018, в 23:48
0

@PaulPatt, как правило, программное обеспечение, которое работает с базами данных, хочет полностью контролировать схему. Обычно никто не будет динамически вызывать такие вещи, как ALTER TABLE или CREATE TABLE, за исключением процедур обновления / установки. Схемы базы данных должны быть исправлены.
Evert 20 фев. 2018, в 23:50
0

@ Я думаю, что научить нормализации не входит в рамки комментария. Вопрос крайне открытый. Я согласен с вашими ответами, но это не маленькая дискуссия. Я не пытался быть грубым, но я думаю, что почти невозможно научить этому несколько персонажей одновременно.
T Gray 20 фев. 2018, в 23:56
0

@TGray, да, я просто нахожу комментарий, похожий на: да, есть проблема с вашим дизайном, иди получить степень магистра в CS. Ответ где-то там. Если есть настоящая проблема нормализации, я думаю, что это должно быть легко указать, в противном случае я не верю, что вы на самом деле понимаете это правильно;) У меня есть догадка, на что вы могли ссылаться (user_id / id выглядит довольно похоже. Это наверное одно и то же поле?)
Evert 21 фев. 2018, в 00:06
0

Evert - я хочу, чтобы вы хотели, чтобы программное обеспечение полностью контролировало схему, но именно программное обеспечение выполняет ALTER TABLE, чтобы добавить больше столбцов, поэтому оно имеет над ним контроль. Моя проблема заключается в чрезвычайной сложности операторов SQL, когда данные распределены по нескольким строкам, как в методе 1.
Paul Patt 21 фев. 2018, в 00:28
0

@PaulPatt Я думаю, что в основном программные проекты видят свои опции в виде схем базы данных, которые динамически изменяются по сравнению с таблицами ключ-> значение, и рассматривают динамическое изменение схем как ценность как двух вариантов. Я думаю, что я бы интуитивно согласился.
Evert 21 фев. 2018, в 00:29
0

Когда я сказал «стоит», я имел в виду «хуже». Я предполагаю, что довольно сложно управлять базовой схемой по умолчанию + миграции для будущих обновлений + все, что пользователь мог добавить к нему (но, вероятно, не должно было).
Evert 21 фев. 2018, в 01:21

Показать ещё 11 комментариев