Рекомендации по проектированию базы данных SQL (адреса)

Конечно, я понимаю, что не существует единого «правильного способа» разработки базы данных 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, я бы просто добавил его в одном месте, а не в каждую таблицу. Однако я вижу, что количество JOIN, необходимых для построения запросов, может показаться немного безумным.

Думаю, мне просто интересно, применяли ли когда-либо этот подход успешно какие-либо архитекторы SQL на уровне предприятия или создаваемое при этом количество JOIN создает проблемы с производительностью?