多语言医学数据库的帮助

Question

我的项目是为许多国家的药品设计一个数据库。

• 药品有多种标准，如成分、价格、制造商等。
• 数据库将是多语言的，与每个国家有关。
• 数据库的大小将随着时间的推移而增加。
• 数据库将不仅仅是关于药物的其他数据，因此随着时间的推移，它将变得更加复杂。

我应该为每个国家建立一个单独的数据库吗？

我使用Server 2008。

Answer 1

不，你不应该把它分成不同的数据库。这将导致更多的问题和复杂性，在更深的线，报告越国，可能需要跨数据库所有权链，等等。

您可以通过规范化过程来实现您的需求。许多人说，他们通过查看所需的属性并通过“感觉”将它们分成不同的实体，从而实现了数据库的规范化。然而，适当的规范化是一种更为正式、结构化的方法，适用于良好的数据库设计。在http://en.m.wikipedia.org/wiki/Database_归一化和Itzik的书There查询中有一篇很好的维基百科文章，其中也有很多详细的例子。

还建议您使用完整的ERD (实体关系图)验证您的规范化，您的规范化和ERD也是项目文档库中非常有用的设计文档。

Answer 2

通常，不应将一组逻辑数据分成不同的数据库。它带来的效益很小，使行政和发展更加困难。有例外，听起来你没有例外。

属性分割

将一组逻辑数据放置在模式中的多个位置称为属性拆分。Joe在他的书SQL for Smarties：

属性分裂有多种形式。当您有一个属性，但将其值放在架构中的多个位置时，就会发生这种情况。最常见的属性分割形式是为每个值创建单独的表。属性拆分的另一种形式是在同一表中为每个值的一部分创建单独的行。

他接着介绍了一个典型的表级属性分割示例：

如果我要创建一个数据库，为男性雇员创建一个表，为女性雇员创建一个单独的表，您将立即看到它们应该是一个包含性别代码列的表。我会在性问题上分桌。这是非常明显的，但它也可以更微妙。

如果要为每个国家的医药数据创建一个单独的数据库，那么您将在数据库级别对country属性进行拆分。

拆分数据库

的实际原因

在他的分裂数据文章中，Joe给出了列拆分、表拆分和模式(或数据库)拆分的示例。他承认，数据库拆分有时是一种实际的必要性：

极端的情况是将数据放入多个数据库。大多数情况下，这是出于必要的。将所有企业数据放入一个集中式数据库并不总是在物理上或实际上可能的。只要它是合乎逻辑的，并且有很好的控制，这是好的。我们需要一个企业的单一数据模型。这是联邦数据库类似于分区数据库的地方。在联邦数据库中，系统维护数据库之间的关系，并且(我们希望)保持数据的一致性(例如，每个DB都在UTC上，一组度量，等等)。因此数据属于一个中心数据模型，而不是一组不匹配的本地数据模型。

拆分数据库的一个实际原因是，如果您的数据比系统在单个数据库中所能管理的数据更多的话。例如，如果您有10 GB以上的数据，并且受制于服务器版的局限性，则必须将数据存储在多个数据库中。

分裂数据库

引起的

问题

除非您能够确定一个数据库中存在太多的实际问题，否则增加的复杂性肯定不值得。联邦数据库系统是一个分布式系统，比单个数据库更难管理。

例如，如果有多个数据库，则无法保证备份的原子性，因为系统备份在数据库级别工作。如果要备份多个数据库，如何确保从备份中还原将所有数据库返回到一致的时间点？

类似地，Server无法保证跨数据库的引用完整性。不能在一个数据库中声明引用另一个数据库中的列的外键列。如果您的数据的完整性对您很重要，您应该设计您的数据库，以便系统能够自动确保其完整性。

正如皮特·卡特( Pete )在他的回答中所解释的那样，在所有国家查询和报告都会更加困难。

‘为安全而拆分’

您还没有指定访问要求，但让我提出一个建议。一项假想的商业要求可能诱使设计师拆分数据库，这将是一项安全规则，一国的经营者不应能够查看另一国的医药数据。

通过拆分数据库来实现此要求的一个常见论点是，很容易限制在数据库级别上的访问。

Server提供了在不创建多个数据库的情况下保护数据的方法。您可以创建每个国家的视图，并且只允许通过视图访问数据。