0

У меня есть дизайнерская дилемма; С одной стороны (вариант 1) я только создаю адресную таблицу один раз, но с другой стороны (вариант 2) кажется, что у него будут преимущества производительности ... меньше объединений и меньше данных. Ребята, что вы думаете?SQL Database Design

enter image description here

+1

У вас есть несколько адресов для каждой стороны? – Harsh

+0

Да, я знаю, его отношение ко многим отношениям – DonkeySticks

+0

@ eugv86 Как у вас есть отношения друг к другу между клиентом/сотрудником/контактом и адресом? В большинстве сценариев одному клиенту/сотруднику/контакту выделяются два адреса. – HappyCoding

ответ

0

Вариант 1 точно. Все ваши адреса должны быть в одном месте. Это также не должно препятствовать производительности. Вы можете ограничить адреса, возвращаемые оператором WHERE, когда вы запрашиваете данные.

Three customer addresses in one table or in separate tables?
Реферирование вышеупомянутой связи: Так как вы говорите, ваш адрес отношение клиента моделируются как один-ко-многим, я хотел бы использовать следующий пример одной таблицы адресов, в AddressType и EntityId FK. Использование этого метода позволит Entity (client/employee/contact) иметь много адресов.

CREATE TABLE Entity 
(
    ID int not null IDENTITY(1,1) PRIMARY KEY, 
    Name varchar(60) not null, 
    EntityType int not null 
    -- etc 
) 

CREATE TABLE Address 
(
    ID int not null IDENTITY(1,1) PRIMARY KEY, 
    EntityID int not null 
     CONSTRAINT FK_Entity_EntityID FOREIGN KEY References Entity(ID), 
    Street varchar(120) not null, 
    AddressType int not null 
    -- etc 
) 
+0

Вариант Soooooo 1 без таблицы переходов .... – DonkeySticks

+1

Этого недостаточно, чтобы представить случай, когда 1 адрес сопоставляется с N сущностями. Связь между сущностью и адресом - NxM. – Ivo

0

Вариант 1 лучше с точки зрения дизайна. Одна таблица должна иметь все адреса - и соответственно обновляться. Таким образом, вы можете легко создавать отношения между адресами и клиентом, сотрудниками и контактами (и все остальное на самом деле) и делать такие запросы, как: «выбрать все, что живет в X-адресе». Имейте в виду, что таким образом вам придется правильно поддерживать таблицу адресов - управлять повторяющимися адресами, убедиться, что адрес правильный и т.д.

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

Все сводится к тому, что вам нужно в конце.