情况：我们正在开发一个项目，将数据源读入我们公司的数据库。这些数据馈送可以包含大量字段。我们将这些字段与某些列匹配。
目前我们有大约120种类型的领域。这些都需要一个专栏。我们需要能够过滤和排序所有列。
问题在于我不确定哪种数据库设计最适合这种情况。我正在使用MySQL来完成工作，但我很乐意接受建议。此刻，我打算制作一张包含所有120列的表格，因为这是最自然的做事方式。
选项：我的其他选项是存储键和值的元表。或者使用基于文档的数据库，这样我就可以访问变量模式并在需要时进行扩展。
问题： 存储所有这些数据的最佳方法是什么？行数可能高达100k行，我需要一个可以快速选择，排序和过滤的存储。
更新 有关使用的更多信息。 XML源将从此表生成。我们说的是每小时100到500个请求，但这种情况会越来越多。这些领域不会定期更改，但可能每6个月更换一次。我们还将每天更新数据馈送。因此，检查项目是否已更新并删除旧项目并添加新项目。
答案 0 :(得分：1)
100k行的120列信息不足，只能真正给出一个指标：大小。另一个是交易。你在这里谈论每秒多少笔交易？
这是一个每晚更新一次，经理每周运行一次报告，还是每小时一百万次请求？
我通常不需要开始查看'聪明'的解决方案，直到达到10米记录表或每秒数百个查询。
哦，不使用键值对表。它们在关系数据库中不是很好，所以坚持使用正确的类型字段。
我个人建议坚持使用传统的每列一列方法，只有在测试显示它真的不对时才会偏离这一点。
关于检索，如果INSERTS / UPDATES只是每天发生，那么我认为在服务器端进行一些仔细的索引，以及在生成XML的任何地方进行良好的缓存都应该减少服务器的数量。 例如，您说'我们将每天更新数据源'，那么每次都不应该需要查询数据库。虽然，每小时1000只，每分钟只有17次。这可能会一事无成。
答案 1 :(得分：0)
我正在研究一个类似的项目，从网上下载转储并将它们加载到数据库中，将更改合并到主表中并正确调整字典表。
首先，您知道您将要使用的数据。因此有必要提前分析并选择最佳的表/列布局。如果您的所有120列都包含文本数据，那么单行将占用几个K字节的磁盘空间。在这种情况下，您将希望使所有查询具有高选择性，以便使用索引来最小化IO。对于这样的设计，完全扫描可能需要很长时间。你没有说过你的500 / h请求有多大，每个请求会提取一行，一小行或一大部分（直到整个表）？
其次，查看数据时，您可能会列出一些具有有限值集的列。我更喜欢对这些列进行以下转换：
转换是用C编写的触发器完成的，所以虽然它给我上传惩罚，但我确实有一些好处：
第三，尝试根据您将要执行的提取来分割数据。通常情况下，表中只有30-40％的字段通常被所有查询使用，其余60-70％均匀分布在所有字段中并部分使用。在这种情况下，我建议相应地拆分主表：提取总是用于单个“主”表的字段，并为其余字段创建另一个字段。事实上，你可以有几个“另一个”，逻辑上将数据分组到一个单独的表中。
在我的实践中，我们有一个包含客户详细信息的表格：姓名详细信息，地址详细信息，状态详细信息，银行详细信息，账单明细，财务详细信息和一组自定义注释。这样的表上的所有查询都是昂贵的，因为它在我们的大多数报告中使用（报告通常执行完全扫描）。将此表拆分为一组较小的表并在其上构建一个带有规则的视图（为了使外部应用程序感到满意），我们设法获得了令人愉快的性能提升（抱歉，不再有数字）。
总结一下：您知道将要使用的数据，并且您知道将用于访问数据库，进行相应分析和设计的查询。