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

Question

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

我看到两个选项：

1. 我们为每个组织创建一个表，如OrgCustomer，OrgDistributor，OrgVendor等...所有表都具有类似的结构，一些表将有额外的特殊字段，如客户有一个字段HomeAddress（其他组织表没有）..反之亦然。

2. 我们创建一个通用的OrgMaster表并将所有diff Orgs存储在一个地方。该表将具有OrgType字段以区分Orgs的diff类型。并且特殊字段将附加到OrgMaster表中（只有相关的组织记录在这些字段中具有值，在其他情况下它将为NULL）

一些优点＆amp; ＃1的缺点：

优点：

• 它有助于在访问diff类型的组织数据时分配负载，所以我相信这可以提高性能。
• 提供适用于任何特定组织表的完整范围，而不会影响其他现有组织类型。
• 不确定diff / distributed表上的diff索引是否比单个大表更好。

CONS：

• 设计复制。如果我必须增加ZipCode字段的大小 - 我将在所有表中执行此操作。
• 操作实现中的复制（即我们已经使用存储过程进行CRUD操作，因此复制变为n-fold .. 3-4 Inert SP，2-3 SELECT SPs等...）
• 从DB约束\索引到SP到应用程序代码中的Business对象，一切都在增长n倍。
• 在一个地方改变（普通）也必须在所有其他地方进行。

一些优点＆amp; ＃2的缺点：

优点：

• N倍变为1倍： - ）
• 维护变得简单，因为我们可以尝试为所有操作实现单个入口点（即单个SP来处理CRUD操作等）。
• 我们要担心维护单个表格。索引和其他优化仅限于一个表。

CONS：

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

我还想到了选项＃3 - 将Org表保持独立，但创建了一个公共的OrgAddress表来存储公共字段。但这让我处于＃1＆amp; ＃2，它正在制造更多的混乱！

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

提前致谢。随意询问任何技术问题＆amp;欢迎提出建议。

与Hemant

Answer 1

我已经开发了各种已经实现了所有选项的应用程序。说实话，您可能需要考虑用户使用数据的方式，您期望的记录数，通用性（具有多个功能的同一组织）以及您期望的记录的更新级别。 / p>

选项1在一个几乎没有共性的应用程序中运行良好。我已经在应用程序中使用了有效的选项3，其中存在更多的共性，并且不太喜欢它（在所有时间从不同层获取数据涉及更多工作）。重写此应用程序正在实施您的选项2。

HTH

Answer 2

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

客户，分销商，供应商是组织的类型，因此我建议：

1. 表[组织]，其中包含所有组织共有的所有列以及该行的主键。

2. 单独的表[供应商]，[客户]，[分销商]，每个表的特定列和FK到[组织]行PK。

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