0

我正在努力寻找构建适合我的项目的结构的最佳方法。答案可能很简单，但由于列或表的数量庞大，我正在苦苦挣扎，具体取决于它的设置方式。

我们有几个工具，每个都可以为许多客户运行。每个工具都有一系列问题，这些问题填充了答案数据库。工具运行后，我们填充另一系列数据，即工具的输出。我们有大约 10 个工具，都填充了一个包含 1500 个数据点的电子表格。这就是我挣扎的地方......每个工具都可以运行多次，并且许多工具共享相同的数据点。我的下一个项目是构建一个可以开始为工具输入数据的应用程序，但允许导入与已运行的工具共享相同数据点的数据。

一个简单的例子：工具 1 - 公司、用户数量、位置数量、成本 工具 2 - 公司、用户数量、总存储量、员工工资率

因此，如果同一家公司完成了工具 1，我需要能够在他们完成工具 2 时填充“用户数”（或提供填充），因为它已经存在。

我认为归根结底是，最好创建一个具有 1500 个表的结构，每个数据元素 1 个表，每个数据元素周围都有额外的数据，或者创建一个大表 - 比如......

customerID(FK), EventID(fk), ToolID(fk), numberofusers, numberoflocations, cost, total storage, employee pay,.....(1500)

如果我走这条路并拥有一张大桌子，我不确定这将如何影响性能。同样 - 维护 1500 个表将是多么困难。

另一个维度是最好有每个字段的描述：numberofusers,title,description,active(bool)。我认为这只有在每个元素都在自己的表中时才有可能？

想法？建议？抱歉这个冗长的问题，这里是新的。

4

2 回答 2

0

构建一个包含所有常见数据的主表：公司、# 用户、.. 其他内容。给每一行一个唯一的ID。

为每个独特的工具构建一个表格，其中包含上面的公司 ID 以及该实施所特有的任何数据。为每个表提供“工具使用”和“公司”的主键（唯一键）。

这涵盖了一个地方的公共数据，识别每个“客户”并为每个客户提供给定工具的多种用途。每次使用和客户都是可跟踪且不同的。

更多关于标准化here。

于 2013-04-11T20:08:19.783 回答
0

我同意 etherbubunny 关于标准化的观点，但是对于更大的数据集，性能方面的考虑很快就会变得很重要。规范化数据库中通常需要连接以显示人类可读信息，即使在中等大小的表上也可能成为性能杀手，这就是为什么许多数据仓库模型使用非规范化数据集进行报告的原因。这实质上是将连接的报告数据预先构建到新表中，并大量使用索引、归档和分区。

在许多情况下，智能地使用分区本身也可以有效地帮助减少被查询的数据集的大小。除非某些参数保持固定，否则这通常需要相当多的维护。

最终，在您的情况下（以及大多数其他情况），我强烈建议您以能够维护和理解正在发生的事情的方式构建它，然后通过慢查询日志、解释和性能监控工具（如 percona 的工具集）执行定期性能检查。这将使您深入了解真正发生的事情，并为您提供一些数据以供您返回此处或 MySQL 论坛。我们总是可以在这里推测，但最终真实数据和您的设置将成为适合您的驱动力。

于 2014-04-23T01:44:16.687 回答