数据库优化：散列所有值

Question

通常，数据库设计如下，以允许实体的多种类型。

实体名称 类型 其他信息

实体名称可以像帐户数量和类型也能像储蓄，在银行数据库例如电流等。

大多数情况下，类型将是某种字符串。可能会有与实体类型相关的其他信息。

通常情况下查询将会像这样。 查找此特定类型的帐号？ 查找类型X的账号，余额大于100万？

要回答这些查询，查询分析器将在索引与特定列关联时扫描索引。否则，它会对所有行进行全面扫描。

我在考虑下面的优化。 为什么不在实际表中存储每列数据的散列值或整数值，以便保持排序属性，以便于比较。

它具有以下优点。 1.表格大小会少得多，因为我们将为每个列数据存储小尺寸值。 2.我们可以在每个列的哈希值上构建一个聚集的B +树索引，以检索匹配或者大于或小于某个值的相应行。 3.通过在主存储器中使用B +树索引并检索相应的值，可以轻松检索相应的值。 4.不需要检索不频繁的值。

我在脑海里仍然有更多的优化。我会根据对这个问题的反馈发布这些内容。

我不确定这是否已经在数据库中实现，这只是一个想法。

感谢您阅读本文。

- 巴拉

更新：

我不是试图仿效数据库做什么。通常，索引由数据库管理员创建。我试图通过在数据库中的所有字段上使用索引来提出物理模式，以便减少数据库表大小，并且很容易回答少量查询。

更新：（乔的回答）

如何添加索引，以每场减少数据库的大小？除了散列之外，你还必须存储所有的真值。我们不只是想查询存在，而是想返回实际的数据。

在典型的表格中，所有的物理数据都将被存储。但现在通过在每列数据上生成散列值，我只将散列值存储在实际表中。我同意它不减小数据库的大小，但它减小了表的大小。当你不需要返回所有的列值时，它会很有用。

大多数关系数据库现在能够有效地回答大多数查询（尤其是关键指标就位）。我很难制定数据库更高效并节省空间的情况。

在表上只能有一个聚簇索引，其他所有索引都必须有非聚簇索引。用我的方法，我将对数据库的所有值进行聚集索引。它会提高查询性能。

将索引放在物理数据中 - 这实际上没有意义。索引性能的关键是每个索引都按照排序顺序存储。如果他们只在物理布局中存储一次，您如何在任何可能的领域提出这样的建议？最终，实际的行必须按照某种东西排序（在SQL Server中，例如，这是聚集索引）？

其基本思想是，不是为每个列创建一个单独的表以提高访问效率，而是在物理层面进行。

现在，表格将如下所示。

ROW1 - OrderedHash（列1），OrderedHash（列2），OrderedHash（栏3）

Answer 1

Google for“hash index”。例如，在SQL Server中，使用CHECKSUM函数创建和查询这样的索引。

当你需要索引包含长值的列，例如这主要是有用平均超过100个字符或类似的字符。

Answer 2

如何添加索引，以每场减少数据库的大小？除了散列之外，你还必须存储所有的真值。我们不只是想查询存在，而是想返回实际的数据。

大多数关系数据库现在能够有效地回答大多数查询（特别是关键指标就位）。我很难制定数据库更高效并节省空间的情况。

将索引放入物理数据中 - 这实际上没有意义。索引性能的关键是每个索引都按照排序顺序存储。如果他们只在物理布局中存储一次，您如何在任何可能的领域提出这样的建议？最终，实际的行必须按照某种东西排序（在SQL Server中，例如，这是聚集索引）？

Answer 3

我不认为你的方法是非常有帮助的。

与几乎每个数据库索引相比，哈希值仅有助于平等/不平等比较，但不会低于/高于比较。

即使有（相等）散列函数也不能100％保证给出了正确答案，因为散列冲突可能发生，所以您仍然必须获取并比较原始值 - 繁荣，您刚刚丢失你想要保存什么。

您可以让表中的行一次仅排序一次。因此，如果您有一个应用程序，您必须在不同的查询中对行进行不同的排序（例如，查询A需要按其名称排序的客户列表，则查询B需要按其销售量排序的客户列表），其中一个查询将具有不按顺序访问表格。

如果您不希望数据库必须解决您在查询中不使用的列，那么请使用具有额外数​​据列的索引 - 如果您的查询按照该索引进行排序，并且查询只使用列（索引是基于已经明确添加到索引中的加列），DBMS将不会读取原始表。

等等