Я думаю, что и Дэвид Олдридж, и Рэй Мор дали вам потенциально подходящие предложения по дизайну, но я хотел бы ответить на ваш вопрос немного более целостно и сосредоточив внимание на вашем утверждении, что «[вы] задаетесь вопросом, [вы] сделать ошибку проектирования базы данных».
Краткая версия: Да, я думаю, что вы допустили ошибку проектирования — настаиваете на том, чтобы указать данные для входа в систему от одного поставщика в таблице поставщиков — и это приводит к тому, что вы отклоняете оба ваши собственные альтернативные идеи, а также идеи, предложенные другими.
Подробная версия. Во-первых, подумайте об этом концептуально, а не технически. Кому принадлежат данные для входа? Раньше они принадлежали поставщику. Теперь они принадлежат сотруднику поставщика.
Ранее в процессе моделирования данных (то есть до того, как вы дойдете до момента создания физической модели) мы говорим об атрибутах, а не о столбцах, и объектах, а не о таблицах, поэтому данные для входа в систему являются атрибутами сущности сотрудника поставщика, а не атрибутами субъект поставщика. Это означает, что когда вы доберетесь до своей физической базы данных, эти столбцы должны быть в таблице SupplierContact (или связаны с ней).
Так почему же логины всегда принадлежат сотруднику поставщика, а не поставщику? Подумайте об этом сценарии:
Вы работаете с поставщиком, у которого есть один сотрудник, поэтому вы создаете для него один набор данных для входа. Через год бизнес поставщика расширяется, и человек, управляющий им, нанимает помощника — им тоже нужен доступ, поэтому вам нужно сделать еще один набор данных для входа в систему для того же поставщика.
В предлагаемой вами модели вам потребуется удалить текущие данные для входа в систему из таблицы Supplier и добавить два набора данных в SupplierContact. В зависимости от дизайна вашего приложения вам также может понадобиться закрыть исходную учетную запись поставщика или принудительно сбросить их пароль, что может их раздражать.
Альтернативная ситуация. Если у вас есть законная причина иметь два разных типа учетных записей — организационную учетную запись для поставщиков и индивидуальную учетную запись для сотрудников поставщика, — то это другая ситуация. Тем не менее, вы все равно можете достичь обеих целей: иметь все учетные записи в одной таблице, при этом связывая каждый тип учетной записи с соответствующей таблицей (например, Поставщик или ПоставщикКонтакт).
Например, у вас может быть таблица под названием «Учетная запись», в которой хранятся данные для входа. Оттуда есть несколько вариантов, чтобы связать эту таблицу с поставщиком или SupplierContact. Я не хочу вдаваться в вопрос, какой вариант выбрать, так как это вопрос, который хорошо обсуждается в другом месте (в том числе на SO), и, возможно, это вопрос вкуса, но вот некоторые варианты:
- Включите в учетную запись два столбца внешнего ключа, допускающие значение NULL, один из которых может содержать SupplierId, а другой может содержать SupplierContactId. Потенциально создайте ограничение, чтобы гарантировать, что одно из двух всегда заполнено.
- Создайте две отдельные таблицы, SupplierAccount и SupplierContactAccount, с двумя столбцами в каждой. Первый должен иметь столбцы SupplierId и AccountId с внешними ключами для Supplier и Account, а второй должен иметь столбцы SupplierContactId и AccountId с внешними ключами для SupplierContact и Account. Потенциально создайте ограничения, чтобы строки в Account не были связаны более чем с одним Supplier или SupplierContact.
Обратите внимание, что я не стал бы делать вышеописанное, если бы у меня действительно не было двух разных типов аккаунтов. Это усложняет задачу, и ее не следует делать, если в этом нет необходимости; если ваша единственная причина сохранить детали, связанные с поставщиком, заключается в том, что вы привыкли к этой структуре или просто предпочитаете ее таким образом, то не делайте этого.
Еще один вариант: тем временем у меня возникла другая мысль по этому поводу. Я не буду вдаваться в подробности, так как вы уже приняли это и, по-видимому, знаете достаточно, чтобы двигаться дальше, но другим вариантом может быть использование шаблона моделирования данных Party.
Этот шаблон может быть полезен в ситуациях, когда вам необходимо взаимодействовать аналогичным образом как с отдельными людьми, так и с организациями или группами людей. Это также полезно для ситуаций, подобных той, которую упомянул Деннис, когда вы можете взаимодействовать с человеком или организацией несколькими различными способами, т. Е. Сторона может играть более одной роли.
Вот статья об этой идее, которую я нашел полезной, когда впервые столкнулся с ней . Лен Сильверстон, написавший эту статью, также опубликовал несколько очень полезных книг по моделированию данных, если вы хотите получить больше информации. Книги работают от более концептуального/абстрактного уровня вплоть до физических схем баз данных. Если вы поищите в Интернете шаблон модели данных партии, я уверен, что вы сможете найти аналогичные ресурсы в Интернете, если это окажется полезным для вашей ситуации.
04.06.2015
