我正在努力寻找建立适合我项目的结构的最佳方法。答案可能很简单，但由于大量的列或表，我正在努力，这取决于它的设置方式。
我们有几个工具，每个工具都可以为许多客户运行。每个工具都有一系列问题，这些问题填充了答案数据库。运行该工具后，我们将填充另一系列数据，这些数据是该工具的输出。我们有大约10个工具，所有工具都填充了1500个数据点的电子表格。这是我奋斗的地方......每个工具都可以运行多次，而且许多工具共享相同的数据点。我的下一个项目是构建一个可以开始工具数据输入的应用程序，但允许导入与已经运行的工具共享相同数据点的数据。
一个简单的例子： 工具1 - 公司，数量的用户，数量的位置，成本 工具2 - 公司，多个用户，总存储，雇员支付
因此，如果同一家公司完成了工具1，我需要能够在完成工具2时填充“numberofusers”（或提供填充），因为它已经存在。
我认为它归结为，最好是创建一个包含1500个表的结构，每个数据元素1个，每个数据元素周围有附加数据，或创建一个大型表 - 如...
customerID（FK），EventID（fk），ToolID（fk），numberofusers，numberoflocations，cost，total storage，employee pay，.....（1500）
如果我走这条路并有一张大桌子，我不确定这会对性能产生什么影响。同样 - 维持1500个表是多么困难。
另一个方面是，对每个字段进行描述会很好： numberofusers，标题，描述，活性（布尔）。我假设这只有在每个元素都在自己的表中时才有可能吗？
思考？建议？对不起这个冗长的问题，新来的。
答案 0 :(得分：0)
使用所有常见数据构建主表：company，＃users，..其他东西。为每一行提供唯一的ID。
使用上面的公司ID以及该实现独有的任何数据为每个唯一工具构建一个表。为每个表提供“工具使用”和“公司”的主要（唯一键）。
这包括一个地方的公共数据，标识每个“客户”并为每个客户提供给定工具的多种用途。每个用户和客户都是可追踪的。
此处有关normalization的更多信息。
答案 1 :(得分：0)
我同意etherbubunny关于规范化，但是对于更大的数据集，性能因素很快变得重要。在规范化数据库中经常需要显示人类可读信息的联接可能是甚至中等大小的表上的性能杀手，这就是许多数据仓库模型使用非规范化数据集进行报告的原因。这基本上是将加入的报告数据预先构建到新表中，大量使用索引，归档和分区。
在许多情况下，智能地使用分区本身也可以有效地帮助减少被查询数据集的大小。除非某些参数保持不变，否则这通常需要相当多的维护。
最终在你的情况下（以及大多数其他人）我强烈建议你以能够维护和理解发生的事情的方式构建它，然后通过慢速查询日志，解释和性能监控工具（如percona的工具）执行常规性能检查组。这将使您深入了解实际发生的情况，并为您提供一些数据，或者在MySQL论坛中提供。我们总是可以在这里推测，但最终真实数据和您的设置将成为适合您的驱动力。