Когда разбивать большую таблицу базы данных?

Question

Я работаю над базой данных «Сотрудник», и поля начинают складываться (скажем, 20).База данных будет заполняться из другого пользовательского интерфейса, например:

Пользовательский интерфейс личной информации: заполняет поля таблицы «Сотрудник», такие как день рождения, фамилия, пол и т. Д.

Интерфейс сведений о занятости: заполняет поля таблицы «Сотрудник», такие как номер сотрудника, дата найма, уровень обучения и т. Д.

Заполнение всех полей из одного пользовательского интерфейса (как вы можете себе представить) беспорядочнои в результате получается одна очень длинная форма, которую нужно прокрутить.

Я собираюсь разбить эту таблицу на несколько таблиц меньшего размера, чтобы каждая меньшая таблица содержала связанную информацию о сотруднике (т.е.таблица логически согласно пользовательскому интерфейсу).

Затем к таблицам будет добавлен идентификатор сотрудника.Я понимаю, что разбиение таблиц с отношением один к одному , как правило, не очень хорошая идея ( несколько таблиц базы данных ), но может логически разделить таблицу, так что сотрудникинформация фиксируется в нескольких операторах INSERT?

Спасибо.

Answer 1

Ваша модель данных не должна соответствовать каким-либо правилам, налагаемым пользовательским интерфейсом, просто для удобства.Одним из способов уменьшить набор столбцов для данного компонента пользовательского интерфейса является использование представлений (в большинстве баз данных вы также можете INSERT / UPDATE / DELETE использовать простые представления).Другой - избегать SELECT *.Вы всегда можете выбрать подмножества столбцов вашей таблицы

Answer 2

"Может ли логическое разделение таблицы помочь, чтобы информация о сотруднике была зафиксирована в нескольких инструкциях INSERT?"

Нет.

Как это может помочь?

20fields - довольно небольшое количество полей для реляционной базы данных.Некоторое время назад был вопрос о SO, где разработчик ожидал иметь около 3000 полей для одной таблицы (что на самом деле было за пределами возможностей рассматриваемой СУБД) - при таких обстоятельствах это имеет смыслразделить таблицу.

Может также иметь смысл разделить таблицу, если подмножество столбцов будет заполняться только для небольшого количества строк (например, если были атрибуты, которые былиспециально для директоров компаний).

Однако, исходя из предоставленной информации, нет очевидных причин для разделения таблицы.

Answer 3

Короче говоря, вы хотите нормализовать модель данных.Нормализация - это систематическая реструктуризация данных в таблицы, которые сформировали теоретическую основу реляционной модели данных, разработанной Э. Ф. Коддом сорок лет назад.Существуют уровни нормализации - ненормализованные, а затем нормальные формы первой, второй, третьей и т.д.*

Я нашел потрясающую сводку на сайте IBM, которая может помочь в нормализации.http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.ddi.doc/ddi56.htm

Оригинальная книга Кодда, позже переработанная CJ Date, не очень доступна, к сожалению.Я могу рекомендовать «Системы баз данных: проектирование, внедрение и управление; авторы: Роб, П. и Коронель, КМ».Я провел урок по проектированию баз данных, в котором использовался этот учебник, и продолжал использовать его для справки.