SQL-Server DB 设计时场景（分布式或集中式）答案

【问题标题】：SQL-Server DB design time scenario (distributed or centralized)SQL-Server DB 设计时场景（分布式或集中式）
【发布时间】：2009-10-26 08:41:55
【问题描述】：

我们有一个 SQL Server 数据库设计时场景 .. 我们必须在我们的数据库中存储有关不同组织的数据（即像客户、供应商、分销商......）。所有 diff 组织共享相同类型的信息（几乎）.. 例如地址详细信息等...并且它们将在其他表中引用（即通过 OrgId 链接，我们必须在许多 diff 位置查找 OrgName）

我看到了两个选项：

我们为每个组织（如 OrgCustomer、OrgDistributor、OrgVendor 等）创建一个表...所有表都将具有相似的结构，并且一些表将具有额外的特殊字段，例如客户具有字段 HomeAddress（另一个组织表没有）.. 反之亦然。
我们创建一个通用的 OrgMaster 表并将所有 diff Orgs 存储在一个位置。该表将有一个 OrgType 字段来区分 Orgs 的不同类型。并且特殊字段将附加到 OrgMaster 表中（只有相关的 Org 记录才会在这些字段中具有值，在其他情况下为 NULL）

#1 的一些优点和缺点：

优点：

它有助于在访问 diff 类型的 Org 数据时分配负载，因此我相信这会提高性能。
在不影响其他现有 Org 类型的情况下，为自定义任何特定 Org 表提供完整范围。
不确定差异/分布式表上的差异索引是否比单个大表更好。

缺点：

复制设计。如果我必须增加 ZipCode 字段的大小 - 我必须在所有表格中这样做。
操作实现中的复制（即，我们已将存储过程用于 CRUD 操作，因此复制进行 n 倍 .. 3-4 Inert SP、2-3 SELECT SP 等...）
从 DB 约束\索引到 SP 到应用程序代码中的业务对象，一切都增长了 n 倍。
一个地方的更改（常见）也必须在所有其他地方进行。

#2 的一些优点和缺点：

优点：

N-fold 变成 1-fold :-)
维护变得容易，因为我们可以尝试为所有操作实现单个入口点（即单个 SP 来处理 CRUD 操作等）
我们不得不担心维护一个表。索引和其他优化仅限于单个表。

缺点：

它会造成瓶颈吗？是否可以通过实施 Views 和其他优化的数据访问策略来管理？
集中实施的另一面是必须在所有地方测试和验证单个更改。它不是抽象的。
设计可能看起来不太“有条理\结构化”，尤其是。由于我们需要为其添加“特殊”字段的少数组织（与其他表无关）

我还想到了一个选项#3 - 将 Org 表分开，但创建一个通用 OrgAddress 表来存储通用字段。但这让我处于 #1 和 #2 的中间，并且造成了更多的混乱！

说实话，我是一名经验丰富的程序员，但不是同样经验丰富的 DBA，因为这不是我的主要工作，所以请帮助我在设计复杂性和性能等参数之间做出正确的权衡。

提前致谢。欢迎提出任何技术问题和建议。

赫曼特

【问题讨论】：

标签： sql-server database-design distributed centralized

【解决方案1】：

我会说你的第二个选项很接近，只有几点：

客户、分销商、供应商是组织的类型，所以我建议：

表 [Organization]，其中包含所有组织共有的所有列和行的主键。
将表 [Vendor]、[Customer]、[Distributor] 分开，每个表都有特定的列，FK 到 [Organization] 行 PK。

听起来像是“超类型/子类型关系”。

【讨论】：

不要忘记.. 子类型（供应商、客户、分销商）中的主键通常用作 FK，因此与超类型（组织）表中的主键相同。
谢谢。如果我考虑建议#2 - 特定列的单独表..我同意它有一个清晰的结构（除了管理这些单独的表的一些额外开销..但我们可以忍受它）我想知道这是否容易创建一个视图来帮助我结合 OrgMaster 和 Special field .. 还是拥有一个附加了所有特殊 Org 字段的 OrgMaster 更好？这与建议#2 重叠 .. 但我们必须从维护的角度考虑性能和复杂性。请告诉我。
分离会更好，因此请实施建议 1 和 2。在 OO 设计中，将具有类“clsOrganization”，而类“clsVendor”、“clsDistributor”和“clsCustomer”将从“clsOrganization”继承"并且每个都有自己的特定属性。在 SQL 中，这是尽可能接近的。创建 JOIN 时，只需从子类型开始“思考”：CREATE VIEW v_Vendors AS SELECT * FROM [Vendor] as v JOIN [Organization] as o ON v.ID = o.ID;

【解决方案2】：

我参与过各种应用程序，这些应用程序实现了您的所有选项。老实说，您可能需要考虑用户使用数据的方式、您期望的记录数、共性（具有多种功能的同一组织）以及您期望的记录更新级别。

选项 1 在通用性很少的应用中运行良好。我已经在一个应用程序中使用了你的选项 3，其中有更多的共性，并且不太喜欢它（一直需要更多的工作来从不同的层获取数据）。因此，此应用程序的重写正在实施您的选项 2。

HTH

【讨论】：

谢谢，正如我所提到的 - Org 数据将像查找一样使用（我们将 OrgId 存储在其他表中，因此我们必须在屏幕上显示数据时（或在检查时获取相关的 ORg 详细信息）该记录和其他类似情况的组织访问权限）组织维护是有限的（管理员很少编辑它们）但组织数据访问必须快速高效..数据访问处理负载最少。PS：也请在 Damir Sudarevic 的回复后参考我的评论（它是 Option#2 的扩展）。
由于我在上面第二段中概述的原因，这些 cmets 更倾向于您的原始选项 2。