SQL Server数据库设计时间场景（分布式或集中式） [英] SQL-Server DB design time scenario (distributed or centralized)

问题描述

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

We've an SQL Server DB design time scenario .. we've to store data about different Organizations in our database (i.e. like Customer, Vendor, Distributor, ...). All the diff organizations share the same type of information (almost) .. like Address details, etc... And they will be referred in other tables (i.e. linked via OrgId and we have to lookup OrgName at many diff places)

我看到两个选项：

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

1. We create a table for each organization like OrgCustomer, OrgDistributor, OrgVendor, etc... all the tables will have similar structure and some tables will have extra special fields like the customer has a field HomeAddress (which the other Org tables don't have) .. and vice-versa.

我们创建一个常见的OrgMaster表，并将所有的差异组织存储在一个地方。该表将有一个OrgType字段来区分组织的差异类型。特殊字段将被附加到OrgMaster表（只有相关的组织记录将在这些字段中具有值，在其他情况下将为NULL）

We create a common OrgMaster table and store ALL the diff Orgs at a single place. The table will have a OrgType field to distinguish among the diff types of Orgs. And the special fields will be appended to the OrgMaster table (only relevant Org records will have values in such fields, in other cases it'll be NULL)

缺点＃1：

PROS：

• 它有助于在访问差异类型的组织数据时分发负载，因此我相信这会提高性能。


• 提供一个完整的范围，用于自定义任何特定的组织表，而不影响其他现有的组织类型。


• 不确定diff /工作更好，然后一个大的桌子。

CONS：

• 设计复制。如果我必须增加ZipCode字段的大小 - 我必须在所有表中执行。


• 在操作实现中复制（即我们已经使用了CRUD操作的存储过程复制变为n倍。3-4惰性SP，2-3选择SP等）


• 一切从DB constraint \indexing到SP到应用程序代码中的业务对象。


• 还必须在其他所有地方更改（常见）。

• Replication of design. If I have to increase the size of the ZipCode field - I've to do it in ALL the tables.
• Replication in manipulation implementation (i.e. we've used stored procedures for CRUD operations so the replication goes n-fold .. 3-4 Inert SP, 2-3 SELECT SPs, etc...)
• Everything grows n-fold right from DB constraints\indexing to SP to the Business objects in the application code.
• Change(common) in one place has to be made at all the other places as well.

PROS：

• N折成为1倍： - ）


• 维护变得容易，因为我们可以尝试并实现所有操作的单个入口点（即单个SP来处理CRUD操作等） 。）


• 我们必须担心维护一个表。索引和其他优化仅限于单个表。

CONS：

• 是否创建瓶颈？可以通过实现意见和其他优化的数据访问策略进行管理吗？


• 集中实现的另一面是必须在所有地方进行一次更改。这不是抽象的。


• 设计可能看起来稍微有点有组织的。由于我们需要添加特殊字段的几个组织（与其他表无关）

我也有考虑到选项＃3 - 保持组织表分开，但创建一个常见的OrgAddress表来存储公共字段。但这让我在＃1& ＃2，它正在创造更多的混乱！

I also got in mind an Option#3 - keep the Org tables separate but create a common OrgAddress table to store the common fields. But this gets me in the middle of #1 & #2 and it is creating even more confusion!

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

To be honest, I'm an experienced programmer but not an equally experienced DBA because that's not my main-stream job so please help me derive the correct tradeoff between parameters like the design-complexity and performance.

提前感谢。随时要求任何技术疑问&

Thanks in advance. Feel free to ask for any technical queries & suggestions are welcome.

Hemant

推荐答案

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

I would say that your 2nd option is close, just few points:

客户，经销商，供应商是组织的TYPES，所以我建议：

Customer, Distributor, Vendor are TYPES of organizations, so I would suggest:

1. 具有所有组织共同的所有列的表[组织]和该行的主键。

1. Table [Organization] which has all columns common to all organizations and a primary key for the row.

单独的表[供应商]，[客户]，[经销商]，每个具有特定列的单独表格，FK到[组织]行PK。

Separate tables [Vendor], [Customer], [Distributor] with specific columns for each one and FK to the [Organization] row PK.

听起来像一个超类型/亚型关系。

The sounds like a "supertype/subtype relationship".

这篇关于SQL Server数据库设计时间场景（分布式或集中式）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！