我们有一个 SQL Server 数据库设计时场景……我们必须在我们的数据库中存储有关不同组织的数据（例如，客户、供应商、分销商……）。所有 diff 组织共享相同类型的信息（几乎）.. 例如地址详细信息等...并且它们将在其他表中引用（即通过 OrgId 链接，我们必须在许多 diff 位置查找 OrgName）
我看到两个选项：
我们为每个组织创建一个表，例如 OrgCustomer、OrgDistributor、OrgVendor 等……所有表都将具有相似的结构，并且某些表将具有额外的特殊字段，例如客户具有字段 HomeAddress（其他 Org 表没有） ) .. 反之亦然。
我们创建一个通用 OrgMaster 表并将所有 diff Orgs 存储在一个地方。该表将有一个 OrgType 字段来区分 Orgs 的不同类型。并且特殊字段将附加到 OrgMaster 表中（只有相关的 Org 记录才会在这些字段中具有值，在其他情况下它将为 NULL）
＃1的一些优点和缺点：
优点：
- 它有助于在访问不同类型的 Org 数据时分配负载，因此我相信这可以提高性能。
- 在不影响其他现有 Org 类型的情况下，提供自定义任何特定 Org 表的完整范围。
- 不确定差异/分布式表上的差异索引是否比单个大表更好。
缺点：
- 复制设计。如果我必须增加 ZipCode 字段的大小 - 我必须在所有表格中这样做。
- 操作实现中的复制（即，我们已将存储过程用于 CRUD 操作，因此复制进行 n 倍 .. 3-4 Inert SP、2-3 SELECT SP 等...）
- 从 DB 约束\索引到 SP 到应用程序代码中的业务对象，一切都增长了 n 倍。
- 一个地方的改变（共同）也必须在所有其他地方进行。
＃2的一些优点和缺点：
优点：
- N倍变成1倍:-)
- 维护变得容易，因为我们可以尝试为所有操作实现单个入口点（即单个 SP 来处理 CRUD 操作等）
- 我们不得不担心维护一个表。索引和其他优化仅限于单个表。
缺点：
- 它会造成瓶颈吗？是否可以通过实施视图和其他优化的数据访问策略来管理？
- 集中实施的另一面是必须在所有地方测试和验证单个更改。它不是抽象的。
- 该设计可能看起来不那么“有条理\结构化”，尤其是。由于我们需要为其添加“特殊”字段的少数组织（与其他表无关）
我还想到了一个选项#3 - 将 Org 表分开，但创建一个通用 OrgAddress 表来存储通用字段。但这让我处于#1 和#2 的中间，它造成了更多的混乱！
老实说，我是一位经验丰富的程序员，但不是同样经验丰富的 DBA，因为这不是我的主要工作，所以请帮助我在设计复杂性和性能等参数之间做出正确的权衡。
提前致谢。欢迎提出任何技术问题和建议。
赫曼
