Платформа объекта и проектирование баз данных коллективной аренды
Я смотрю на дизайн схемы базы данных коллективной аренды для понятия SaaS. Это будет ASP.NET MVC-> EF, но это не настолько важно.
Ниже Вас видят схему базы данных в качестве примера (Арендатор, являющийся Компанией). CompanyId копируется всюду по схеме, и первичный ключ был помещен в обоих естественный ключ плюс идентификатор арендатора.
Включение этой схемы в Платформу Объекта дает следующие ошибки, когда я добавляю таблицы в файл (Model1.edmx) Модели Объекта:
- Отношения 'FK_Order_Customer' используют набор внешних ключей '{CustomerId, CompanyId}', которые частично содержатся в наборе первичных ключей '{OrderId, CompanyId}' таблицы 'Order'. Набор внешних ключей должен полностью содержаться в наборе первичных ключей или полностью не содержаться в наборе первичных ключей, которые будут отображены на модели.
- Отношения 'FK_OrderLine_Customer' используют набор внешних ключей '{CustomerId, CompanyId}', которые частично содержатся в наборе первичных ключей '{OrderLineId, CompanyId}' таблицы 'OrderLine'. Набор внешних ключей должен полностью содержаться в наборе первичных ключей или полностью не содержаться в наборе первичных ключей, которые будут отображены на модели.
- Отношения 'FK_OrderLine_Order' используют набор внешних ключей '{OrderId, CompanyId}', которые частично содержатся в наборе первичных ключей '{OrderLineId, CompanyId}' таблицы 'OrderLine'. Набор внешних ключей должен полностью содержаться в наборе первичных ключей или полностью не содержаться в наборе первичных ключей, которые будут отображены на модели.
- Отношения 'FK_Order_Customer' используют набор внешних ключей '{CustomerId, CompanyId}', которые частично содержатся в наборе первичных ключей '{OrderId, CompanyId}' таблицы 'Order'. Набор внешних ключей должен полностью содержаться в наборе первичных ключей или полностью не содержаться в наборе первичных ключей, которые будут отображены на модели.
- Отношения 'FK_OrderLine_Customer' используют набор внешних ключей '{CustomerId, CompanyId}', которые частично содержатся в наборе первичных ключей '{OrderLineId, CompanyId}' таблицы 'OrderLine'. Набор внешних ключей должен полностью содержаться в наборе первичных ключей или полностью не содержаться в наборе первичных ключей, которые будут отображены на модели.
- Отношения 'FK_OrderLine_Order' используют набор внешних ключей '{OrderId, CompanyId}', которые частично содержатся в наборе первичных ключей '{OrderLineId, CompanyId}' таблицы 'OrderLine'. Набор внешних ключей должен полностью содержаться в наборе первичных ключей или полностью не содержаться в наборе первичных ключей, которые будут отображены на модели.
- Отношения 'FK_OrderLine_Product' используют набор внешних ключей '{ProductId, CompanyId}', которые частично содержатся в наборе первичных ключей '{OrderLineId, CompanyId}' таблицы 'OrderLine'. Набор внешних ключей должен полностью содержаться в наборе первичных ключей или полностью не содержаться в наборе первичных ключей, которые будут отображены на модели.
Вопрос находится в двух частях:
- Действительно ли мое проектирование баз данных является неправильным? Я должен воздержаться от этих составных первичных ключей? Я подвергаю сомнению свою исправность относительно фундаментального дизайна схемы (измотанный мозговой синдром). Не стесняйтесь предлагать 'идеализированную' схему.
- С другой стороны, если проектирование баз данных корректно, то действительно ли EF не может соответствовать ключам, потому что это чувствует эти внешние ключи как потенциал, неправильно сконфигурированный 1:1 отношения (неправильно)? В этом случае действительно ли это - ошибка EF и как я могу работать вокруг этого?
2 ответа
При беглом сканировании сообщений об ошибках EF, ему явно не нравится то, как вы устанавливаете составные ключи, и я думаю, что он, вероятно, подталкивает вас в правильном направлении. Подумайте еще раз о том, что делает ваши первичные ключи уникальными. Не уникален ли сам по себе идентификатор заказа без идентификатора компании? Разве идентификатор продукта не уникален без идентификатора компании? Строка заказа, безусловно, должна быть уникальной без идентификатора компании, поскольку строка заказа должна быть связана только с одним заказом.
Если вам действительно нужен CompanyID для всех этих данных, что, вероятно, означает, что компания, о которой идет речь, предоставляет вам ProductID и OrderID, тогда вы можете пойти другим путем и создать собственные первичные ключи, не присущие данным. Просто установите автоинкрементный столбец для вашего первичного ключа, и пусть это будут внутренние OrderID, OrderLineID, ProductID, CompanyID и т.д. В этот момент OrderLine не нужен будет идентификатор заказа клиента или идентификатор компании; ссылка внешнего ключа на заказ будет его отправной точкой. (А CustomerID никогда не должен быть атрибутом строки заказа; это атрибут заказа, а не строки заказа.)
Составные ключи просто беспорядочны. Попробуйте спроектировать модель без них и посмотрите, упростит ли это ситуацию.
Я думаю, что сохранение номера компании в каждой из таблиц больше вредит вам, чем помогает. Я могу понять, почему вы хотите это сделать (как программист / dba вы можете просто зайти в любую таблицу и `` увидеть '', какие данные принадлежат кому-то, что утешает), но это мешает вам настроить базу данных так и должно быть.
Избегайте составных клавиш, и ваш дизайн станет намного проще.