數據庫優化：散列所有值

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將不會讀取原始表。

等等