Конечно, я понимаю, что нет единого "правильного" способа проектирования базы данных SQL, но я хотел бы получить некоторые мнения о том, что лучше или хуже в моем конкретном сценарии.
В настоящее время я разрабатываю модуль ввода заказов (приложение Windows.NET 4.0 с SQL Server 2008), и я разрываюсь между двумя проектными решениями, когда речь заходит о данных, которые можно применять более чем в одном месте. В этом вопросе я буду ссылаться конкретно на адреса.
Адреса могут использоваться различными объектами (заказами, клиентами, сотрудниками, отправками и т.д.), И они почти всегда содержат одни и те же данные (адрес1/2/3, город, штат, почтовый индекс, страна и т.д.). Первоначально я собирался включить каждое из этих полей в виде столбца в каждую из связанных таблиц (например, Заказы будут содержать Адрес1/2/3, Город, Штат и т.д., А Клиенты также будут содержать этот же макет столбца). Но часть меня хочет применить принципы СУХОЙ/Нормализации к этому сценарию, то есть иметь таблицу под названием "Адреса", на которую ссылается внешний ключ в соответствующей таблице.
CREATE TABLE DB.dbo.Addresses
(
Id INT
NOT NULL
IDENTITY(1, 1)
PRIMARY KEY
CHECK (Id > 0),
Address1 VARCHAR(120)
NOT NULL,
Address2 VARCHAR(120),
Address3 VARCHAR(120),
City VARCHAR(100)
NOT NULL,
State CHAR(2)
NOT NULL,
Country CHAR(2)
NOT NULL,
PostalCode VARCHAR(16)
NOT NULL
)
CREATE TABLE DB.dbo.Orders
(
Id INT
NOT NULL
IDENTITY(1000, 1)
PRIMARY KEY
CHECK (Id > 1000),
Address INT
CONSTRAINT fk_Orders_Address
FOREIGN KEY REFERENCES Addresses(Id)
CHECK (Address > 0)
NOT NULL,
-- other columns....
)
CREATE TABLE DB.dbo.Customers
(
Id INT
NOT NULL
IDENTITY(1000, 1)
PRIMARY KEY
CHECK (Id > 1000),
Address INT
CONSTRAINT fk_Customers_Address
FOREIGN KEY REFERENCES Addresses(Id)
CHECK (Address > 0)
NOT NULL,
-- other columns....
)
С точки зрения дизайна мне нравится этот подход, потому что он создает стандартный формат адреса, который легко изменить, то есть, если мне когда-нибудь понадобится добавить Address4, я бы просто добавил его в одном месте, а не в каждой таблице. Тем не менее, я вижу, что количество соединений, необходимых для построения запросов, может стать немного безумным.
Я думаю, мне просто интересно, если какие-либо разработчики SQL уровня предприятия когда-либо успешно использовали этот подход, или количество создаваемых при этом JOIN-соединений создавало бы проблему с производительностью?
