Несколько строк и запятая дизайн колонки в MySQL

У меня есть таблица, где мне нужно добавить строки следующим образом:

id  | empid  | manager | page
------------------------------
1   | emp001 | mg001   | page1
2   | emp001 | mg001   | page2
3   | emp001 | mg002   | page1

Поэтому я не понимаю, использовать ли, как показано выше, или использовать запятую, как,

id  | empid   | manager | page
---------------------------------
1   | emp001  | mg001   | page1,page2,page3,page4.....
2   | emp001  | mg002   | page2,page10,page5,.....

Если я иду с option1, я чувствую, что количество строк продолжает увеличиваться и empid а также mangerid могу повторить Но если я иду с option2, то я чувствую его ненормализованную форму.

Кто-нибудь может предложить, какое решение лучше и почему?

1

Решение

Нет ничего плохого в увеличении количества строк. Реляционные базы данных лучше всего работают с нормализованными данными, и вы можете выполнять эффективные JOIN работа между таблицами с использованием индексов при условии, что вы их создали.

Отсюда и подход, представленный в варианте 1, который фактически передает ваши данные 1NF (первая нормальная форма) намного лучше и не будет кусать вас в будущем, как вариант 2.

Если в будущем у вас может возникнуть идея проанализировать сотрудников и их менеджеров по страницам, то здесь вариант 2 кусает вас.

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

Я считаю следующую схему хорошим началом:

  • Таблица сотрудников, хранящая их идентификаторы как целые числа и имена как текст
  • Управляемая таблица менеджеров аналогична таблице сотрудников
  • Employees_Managers соединение таблица, хранящая ее идентификатор, внешний ключ для Employees.ID и Managers.ID и страницы типа integer
0

Другие решения

YMMV зависит от конкретного варианта использования, но, как правило, — нормализуйте свою базу данных (или, по крайней мере, не нарушайте 1NF, как предлагает второй вариант!), Чтобы вы могли легко запрашивать / обновлять ее. Базы данных созданы для хранения строк и эффективного запроса к ним, и если у вас нет redonculous (читай: как в фейсбуке) количество строк, не пытайся изобретать велосипед.

0

По вопросам рекламы [email protected]