数据集中的表。数量和冗余答案

【问题标题】：Tables in a dataset. Quantity and redundancy数据集中的表。数量和冗余
【发布时间】：2009-06-10 14:27:57
【问题描述】：

对于数据集中使用的表数量，是否有任何最佳做法？在关系数据库中，所有表最终都会关联，那么在创建数据集时我应该具体到多宽？

例如：如果我有一个产品订单的数据集，我是否还应该包括产品表，以及订单所属的客户表、运输信息表等；还是我应该简单地拥有基本的 productorders 表和相关的查找表？

【问题讨论】：

【解决方案1】：

我建议您只将数据集设置为您需要的大小。如果您包含大量很少使用的无关信息，那么您的资源负担将会比您应该的要多得多，而且要多得多。

【讨论】：

【解决方案2】：

“我应该也包括...还是应该简单”

您的用例是什么？人们将如何处理您的数据？这定义了问题域。它准确地定义了必须存在的数据。

附加说明。

首先，表必须映射到问题域中的每个真实事物。询问你的用户他们做了什么，他们做了什么决定，他们采取了什么行动。这将定义现实世界中需要表格的内容。

订单就是一件事。订购的产品是一个东西。客户是一回事。

第二——为了使关系模型工作——你需要对其进行规范化，以便重复元素是表中的行。此外，您需要对其进行规范化，以便每一行都有一个标识符（“键”）用于该行中的一个不同事物。此外，您需要对其进行规范化以删除可导出的数据。

订单上的一行是与订单相关的事物。

产品的特性是与产品整体相关的事物。

这个“规范化”过程为定义关系数据库提供了精确而完整的规则。它准确地告诉您需要多少表来表示问题域中的真实事物。

【讨论】：

【解决方案3】：

我不能说这是否是最佳实践，但在我工作的地方，我们拥有包含超过 75 个表的数据集，它们的性能都很好。有些表只有几条记录，但有些表有数千条记录。我们正在使用二进制远程处理来传输这些表。不确定 xml 序列化是否会给我们相同（甚至接近相同）的性能。上次我检查序列化到磁盘的最大数据集的大小接近 3mb。

还有其他人有处理大型数据集的经验吗？当我们的项目开始时，我从未想过我们需要将这么多的东西打包到一个数据集中，所以我对我们的结果非常满意。

【讨论】：

我实际上是在这种环境中工作的，我可以保证这一声明。我们的数据集表现非常好。从我的角度来看，我在网站上工作，我使用一个非常大的缓存数据集来读取几乎所有的数据。速度相当惊人。然而，这有点极端。至于什么是“最佳实践”。最佳实践是运行良好且易于维护的任何方法。您可以整天整夜听人们对此大肆吹嘘，但最终重要的是它的工作原理和可维护性。

【解决方案4】：

根据用途/逻辑区域进行拆分如果您一起使用一些表，请将它们放在一起。如果某些数据只是参考数据，那么它可能应该进入另一个数据集...如果您正在处理订单 - 仅加载必要的数据。

无论如何，也许您想看看更方便的数据访问方法，例如 ORM？尝试查看 NHibernate，看看它是否适合您的场景......

【讨论】：

【解决方案5】：

我曾经将模型拆分到不同的数据集中。
然而，这已经让我难过好几次了。
当不同数据集中的表之间存在关系/引用时，我不得不编写大量“修复”代码。

1 个大数据集 imo 的唯一两个问题是较慢的设计体验和较慢的对象实例化。（几毫秒）

第二个对我来说没有问题，因为我每个工作单元使用 1 个数据集。

【讨论】：