Включить дополнительные требования в устаревший дизайн базы данных

Question

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

Вот проблемы.

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

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

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

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

3. Я не доволен полем «receive_emails» у пользователей, так как это относится только к пользователям типа «получатель».

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

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

Могу ли я решить проблему с помощью элегантного нового дизайна?

Answer 1

Ну вот еще одна попытка. Я все еще думаю

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

В чем вы обеспокоены в 2, это зависимости. Зависимости обычно не являются проблемой, но вы очень строги в своем дизайне базы данных на основе id, тем самым скрывая зависимости от ваших dbms. Если он просто знал, что это может помочь вам :-)

Вы можете сделать это:

• Придерживайтесь таблицы «пользователей», но удалить company_id.
• Вам не нужно вносить какие-либо изменения в «компании», «пакеты», «участие» и «статусы».
• Добавить таблицу, чтобы связать пользователей с компаниями. Давайте назовем таблицу «принадлежность» на данный момент. (Я не знаю, было ли это подходящее имя, мой английский не смог меня здесь.) Подобно владельцам, это всего лишь таблица ссылок, поэтому единственными полями являются user_id и company_id (формирование первичного ключа).
• Теперь добавьте company_id к «владельцам». (Я знаю, что это неявно из-за вашей ссылки на «пакеты», но dbms этого не знает.) Итак, добавьте поле и теперь, когда ваши dbms видят это поле, вы также можете добавить ограничение (иностранное ключ) на package_id plus company_id на «пакеты» и ограничение на user_id plus company_id на «affilations».

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

Если вы хотите играть в безопасное место с помощью поля receive_emails, то вы можете захотеть пойти (как я уже сказал, это действительно не обязательно): введите новую таблицу email_recipients с двумя полями: user_id и user_type. Да, избыточность снова. Но при этом вы можете иметь ограничение на user_type, разрешая только определенные типы (только «получатель» до сих пор).Снова у вас будет внешний ключ не только для user_id, но и для user_id plus user_type.

Answer 2

Расширить пользователей!

Как и расширение класса, вы можете создать новую таблицу «Менеджеры» с большим количеством столбцов и FK для пользователей.

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

Если вы хотите лучше контролировать этот объект конгломерата, создайте таблицу Конгломерата и создайте FK для менеджеров, так что вы создадите реляционную таблицу между Конгломератом и компаниями ИЛИ, если компания не может принадлежать двум конгломератам только FK от компании для конгломерата.

Answer 3

3: Не беспокойтесь о поле receive_emails. Имейте в виду, что ваша база данных - это всего лишь модель реального мира и не обязательно должна быть идеальной. Да, вы можете сделать «получателей» своей собственной таблицей. Подумайте, что вы получите и что потеряете. Как бы то ни было, это не плохой дизайн. Вы можете использовать триггер, чтобы установить receive_emails в false, если пользователь не является получателем.Или используйте представление, чтобы скрыть поле для приложений, работающих с драйверами или менеджерами. Так же, как вам нравится. Ну, если вы действительно хотите избавиться от поля, вы можете иметь таблицу emeil_recipients, содержащую все идентификаторы пользователей, которые являются получателями электронных писем. Вы видите, что есть много способов решить эту проблему, и все они имеют свои преимущества и недостатки. Ваш дизайн в порядке.

2: Насколько я понимаю, каждый пакет имеет до одного менеджера, одного водителя и одного получателя. Это так? Тогда почему у вас есть таблица «владельцы»? Поместите три поля в таблицу «пакеты»; user_id_driver, user_id_manager, user_id_recipient. Таким образом, ваша модель намного ближе к реальности. (вы можете создать представление «владельцы», чтобы заменить таблицу «владельцы» во время миграции.)

1: Теперь в конгломераты. Проще всего было бы представить две новые таблицы: сначала у вас будет таблица «company_groups» с идентификатором и, возможно, полем описания. У ваших «пользователей» таблицы будет поле «company_group_id», которое заменит поле «company_id». Таким образом, вы связываете пользователей с группами компаний, а не с отдельными компаниями. Ваша вторая новая таблица будет «company_group_members» с двумя полями: id_company_group и id_company. Вы бы создали «группы», состоящие только из одной компании (для менеджеров, получателей и водителей) и групп, состоящих из большего числа компаний (конгломераты для менеджеров конгломератов). Таким образом, ваша база данных не так сильно меняется, но предлагает все, что вам нужно.

Сказав все это, вы все равно можете подумать о том, чтобы уменьшить «пользователей» таблицы в общих полях и иметь новые таблицы «менеджеры», «получатели», «драйверы» и «конгломерации», содержащие дополнительные поля. Это приближает вас к реальности и улучшает связь с пакетами. Тем не менее, это происходит за счет более разной модели от вашего текущего. И что, если вы добавите соавторов, секретарей или что-нибудь еще? Каждый раз, когда новая таблица для новой работы? Опять же: Есть много способов построить свою модель. Выберите тот, который вам подходит.

Надеюсь, мой совет поможет вам все продумать.

Answer 4

мне нужно ввести новый тип пользователя

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

Фактически Управление и Вождение - это роли, которые играет пользователь, который может меняться со временем.
В действительности:
Пользователь is-not-a менеджер (он человек).
Управление is-a-role-by-by пользователь.
Подумайте, если компания решит иметь пользователей справочной службы.

Я добавлю таблицы Role и User-Role, чтобы сохранить связь между пользователем и ролью.

Меня не устраивает поле "receive_emails" у пользователей.

Имея receive-email поле в User-Role будет вариантом.

мне нужно иметь единую точку входа для всех пользователей на моем сайте

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

Я беспокоюсь о цикле зависимостей, сформированном через пользователей, владельцев, пакетов, компаний, пользователей.

Концептуально у нас будет пользователь user-user => owner => package => company => driver или manager.
BTW - реляционная модель.

Конгломераты.