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