SQL 数据库设计最佳实践(地址)

Question

当然，我意识到没有一种“正确的方法”来设计 SQL 数据库，但我想就我的特定场景中的优劣获得一些意见。

目前，我正在设计一个订单输入模块(带有 SQL Server 2008 的 Windows .NET 4.0 应用程序)，当涉及到可以在多个位置应用的数据时，我在两个设计决策之间左右为难。在这个问题中，我将专门提到地址。

地址可以被各种对象(订单、客户、员工、 cargo 等)使用，并且它们几乎总是包含相同的数据(地址 1/2/3、城市、州、邮政编码、国家/地区等)。我最初打算将这些字段中的每一个作为列包含在每个相关表中(例如，订单将包含地址 1/2/3、城市、州等。客户也将包含相同的列布局)。但是我的一部分想将 DRY/Normalization 原则应用于这种情况，即有一个名为“地址”的表，通过相应表中的外键引用。

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 数量是否会产生性能问题？

Answer 1

通过将地址分解到自己的表格中，您走在了正确的轨道上。我会添加一些额外的建议。

考虑从客户/订单表中取出地址 FK 列并改为创建联结表。换句话说，现在在您的设计中将客户/地址和订单/地址视为多对多关系，以便您将来可以轻松支持多个地址。是的，这意味着引入更多的表和连接，但是您获得的灵 active 非常值得付出努力。

考虑为城市、州和国家实体创建查找表。然后，地址表的城市/州/国家列由指向这些查找表的 FK 组成。这使您可以保证所有地址的拼写一致，并在将来需要时为您提供存储其他元数据(例如城市人口)的地方。