Несколько строк и запятая дизайн колонки в 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, то я чувствую его ненормализованную форму.
Кто-нибудь может предложить, какое решение лучше и почему?
2 ответа
Нет ничего плохого в увеличении количества строк. Реляционные базы данных лучше всего работают с нормализованными данными, и вы можете выполнять эффективные JOIN работа между таблицами с использованием индексов при условии, что вы их создали.
Следовательно, подход, представленный в варианте 1, который на самом деле переводит ваши данные в 1NF (первая нормальная форма), намного лучше и не будет вас кусать в будущем, как вариант 2 наверняка.
Если в будущем у вас может возникнуть идея проанализировать сотрудников и их менеджеров по страницам, то здесь вариант 2 кусает вас.
В качестве дополнительного примечания, я думаю, вы могли бы уменьшить объем памяти, необходимый для ваших столбцов, и перестать повторяться, добавив дополнительные таблицы для хранения строк сотрудников и руководителей и ссылаясь на них только целочисленным столбцом. Что касается страниц столбцов, я считаю излишним добавлять часть "страница", чтобы значения столбцов выглядели как "страница X ". Имя столбца уже говорит вам, что оно состоит из значений страницы, поэтому в этом случае также будет достаточно целочисленного столбца X.
Я считаю следующую схему хорошим началом:
- Таблица сотрудников, хранящая их идентификаторы как целые числа и имена как текст
- Управляемая таблица менеджеров аналогична таблице сотрудников
- Соединительная таблица Employees_Managers хранит свой идентификатор, внешний ключ для Employees.ID и Managers.ID и страницы типа integer.
YMMV зависит от конкретного варианта использования, но, как правило, - нормализуйте свою базу данных (или, по крайней мере, не нарушайте 1NF, как предлагает второй вариант!), Чтобы вы могли легко запрашивать / обновлять ее. Базы данных созданы для хранения строк и эффективного запроса к ним, и, если у вас нет повторного количества строк (читай: как в Facebook), не пытайтесь изобретать колесо.