Определение правильных значений ключа для нескольких таблиц MySQL

Question

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

Таблицы сотрудников напрямую связаны с рядом таблиц, которые предоставляют больше информации. Некоторые из этих таблиц имеют еще больше деталей.

• Сотрудники имеют уникальный employeeid , но, насколько я понимаю, лучше всего иметь идентификатор?
• Клиенты имеют уникальный customerid
• У сотрудников есть менеджер
• Менеджеры являются сотрудниками
• У клиентов есть менеджер , связанный с ними. менеджер, связанный с ними
• Сотрудники могут иметь академическую, сертификационную и / или профессиональную информацию.

С учетом всего сказанного, что будет лучшей рекомендацией для создания первичных и внешних ключей? Есть ли лучший способ справиться с дизайном?

---

EDIT

Обновлена ​​диаграмма для отражения обратной связи на данный момент. Смотрите комментарии, чтобы понять происходящие изменения.

Answer 1

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

Диаграмма совершенно неверна. Это поможет вам начать именовать первичные ключи с полным именем, TableNameID, например EmployeeID; тогда станет очевидно, как ключи распространяются через отношения. Если бы у вас были полные имена, вы бы заметили, что все ваши стрелки указывают в неправильном направлении; родитель и ребенок поменялись местами. Во всяком случае, требует некоторой практики. Поэтому я бы предложил вам переработать диаграмму и опубликовать новую версию, чтобы мы могли прокомментировать эту. Это должно начать выглядеть примерно так (просто маленький сегмент)

---

EDIT

Это должно указывать вам на следующий шаг. Посмотрите, можете ли вы прочитать описание (спецификацию) и одновременно следовать схеме.

• Каждый сотрудник имеет одного менеджера , менеджера управляет многими сотрудниками .
• A менеджер - сотрудник .
• Каждый клиент управляется сотрудником, который выступает в роли менеджера по работе с клиентами для этого клиента.
• Аккаунт управляет для клиента со временем может измениться.
• Каждый сотрудник является членом одной команды , каждая команда имеет много сотрудников .
• Производительность сотрудника для каждого сотрудника отслеживается с течением времени.
• Сотрудник может иметь много учетных данных , каждый учетных данных принадлежит одному сотруднику * только 1069 *.
• Полномочия - это академический или профессиональный .

Answer 2

Сотрудники имеют уникальный идентификатор сотрудника, но, насколько я понимаю, лучше всего иметь идентификатор?

Нет.(Но продолжайте читать.) Вам нужен идентификационный номер в двух случаях: 1) когда у вас нет другого способа идентифицировать сущность, и 2) когда вы пытаетесь улучшить производительность соединения.И это не всегда работает.Идентификационные номера всегда требуют большего количества объединений, но когда критическая информация передается в читаемых человеком кодах или в естественных ключах, вам не нужно объединение, чтобы получить к нему доступ.Кроме того, обычное использование идентификационных номеров часто приводит к проблемам целостности данных, поскольку уникальные ограничения на естественные ключи часто опускаются.Например, почтовые индексы USPS для названий состояний уникальны, но в таблицах, в которых вместо почтовых кодов USPS используются идентификационные номера, часто отсутствует уникальное ограничение для этого двухсимвольного столбца.В вашем случае вам нужно уникальное ограничение на количество сотрудников независимо.(Но продолжайте читать.)

У сотрудников есть менеджер.

Выполняет ли таблица «команда» это требование?Если таблица «manager» идентифицирует менеджеров, то другие ваши столбцы менеджера должны ссылаться на «manager».(На этой диаграмме это клиенты, команда и заказчики.)

Менеджеры - это сотрудники.

И эта информация хранится в таблице "менеджер"?

С клиентами связан менеджер, связанный с ними.

Как и каждый заказ.Вы хотели это сделать?

Сотрудники могут иметь академическую, сертификационную и / или профессиональную информацию.

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

---

Всякий раз, когда вы разрабатываете таблицы с перекрывающимися предикатами (перекрывающимися значениями), вам нужно остановиться и сидеть на руках в течение нескольких минут.В этом случае предикаты таблиц «сотрудники» и «клиенты» перекрываются.

Если сотрудники могут быть клиентами, что является случаем почти для каждого бизнеса, то вы установилиэтап для обновления аномалий.Фамилия сотрудника меняется.Понятно, что вы должны обновить «сотрудников».Но вы должны обновить "клиентов" тоже?Откуда вы знаете?Вы не можете сказать, потому что эти две таблицы имеют независимые номера идентификаторов.

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

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

В какой-то момент вам придется поднять свои знания в области проектирования баз данных на следующий уровень.Для раннего начала прочитайте эту статью об именах людей .