如何设计表需要在每个字段上查询？

Question

现在我遇到了一个应用程序要求，需要构建一个可以为每个字段查询的数据库。比如，该表应该有30个字段。

| f1 | f2 | f3 | ...... | f30 |

前端可能需要根据多个甚至所有字段进行查询。例如，需要使用f1 == x AND f2＆lt;来查询所有行。 y和f3＆gt; z AND ... AND f30 = abc。

如果我为每个字段创建索引，则插入和更新操作会很慢。如果我只是索引某些字段，那么使用未编入索引的字段进行查询会很慢。

我认为这是许多应用领域的常见问题。对于这种情况，有没有成熟的解决方案？

Answer 1

您应该将其设置为名称/值对表。字段名称的一个“字段”和值的一个“字段”。您将拥有第三个字段，它将是将所有记录链接在一起的“记录ID”。所以在你的例子中，每个“条目”将有30条记录。那么你只需要在字段名+字段值上有一个索引，并且可以根据需要添加任意数量的“字段”，而无需改变表结构。

Answer 2

索引实现空间/时间权衡。每列的索引

• 消耗更多磁盘空间，
• 使一些SELECT语句更快，
• 使一些INSERT，UPDATE和DELETE语句变慢（因为dbms必须维护索引以及行）。

很少有用户查询会从您的表中选择一组随机列。您可能会发现几乎每个查询中都有两列或三列。这些列上的某种索引将加速使用它们的所有查询。一个好的查询引擎将使用索引来隔离所有行的子集，然后对WHERE子句中所有未编制索引的列对该子集执行顺序扫描。

通常，这对每个人来说都足够快。 （测试，不要假设。）

如果它对每个人来说都不够快，那么你检查查询执行计划和用户查询模式，进行一些性能测量，添加另一个索引，并问自己是否可以接受结果。每个附加索引都会消耗磁盘空间，加速一些SELECT语句，并减慢一些INSERT和DELETE语句。 （用户注意INSERT，UPDATE和DELETE语句的速度是如何减慢的并不常见;它们通常不会减慢速度。）

在某些时候，您可能会发现SELECTERS开始抱怨INSERTers，反之亦然。除非您愿意考虑更具侵入性的性能改进

• 更快的硬件，
• 服务器调整，
• 将一些表或索引移动到更快的磁盘，
• 甚至可能更改为不同的dbms，

你现在有一个政治问题，而不是技术问题。