具有永遠不會改變的數據的表組織

作為參考，我幾乎所有的數據庫經驗都是使用 mongodb，這是我的第一個 postgres 項目。

我正在儲存來自去中心化金融加密池的數據更新。

我正在探索的資料結構非常簡單。有令牌：

type Token =
   {
       Address:    string     // primary key
       Decimals:   int
       Symbol:     string
   }

這些數據永遠不會改變，但會在任何地方被引用；大約 2k 個條目

type LiquidityToken =
   {
       Address:        string    // primary key
       Symbol:         string
       Token0Address:  string    // matches the address from a token above
       Token1Address:  string    // matches the address from a token above
       Timestamp:      DateTime  // changes at every update
       Token0Amount:   decimal   // changes at every update
       Token1Amount:   decimal   // changes at every update
   }

這每 5 分鐘更新一次，但是只有 Token0Amount 和 Token1Amount 發生變化，我想保留歷史記錄。

我大約有 500 個這樣的對象，每 5 分鐘更新一次，因此每天有 140k 新條目。

所以我想做的第一件事是在 Token0/1Address 欄位和 Token 記錄之間進行連接，但是由於 Token 只是添加了一個 int 和一個短（最多 32 個字元，但通常 < 8 個字元）字元串，我想知道這是否節省了很多（我不知道加入佔用了多少空間）。

然後我想知道將對象分成兩部分是否值得：

type LiquidityToken =
   {
       Address:        string    // primary key
       Symbol:         string
       Token0Address:  string    // matches the address from a token above
       Token1Address:  string    // matches the address from a token above
   }

和

type LiquidityTokenUpdate =
   {
       Address:        string    // matches the address of the liquidity token 
       Timestamp:      DateTime  // changes at every update
       Token0Amount:   decimal   // changes at every update
       Token1Amount:   decimal   // changes at every update
   }

並複制這個對象。但是現在一個查詢可能會拉取更新，這會拉取流動性代幣，該代幣必須拉取 2 個代幣對象。

由於這是針對公共 GraphQL 介面的，因此可能會彈出很多使用模式。我無法預測特定類型的查詢，因為這是我想在準備好後向社區公開的內容。

我知道記憶體是我的朋友，因為靜態數據很小，所以它都適合 RAM，但總的來說，嘗試節省空間（每條記錄不是很大）並增加連接或查找的成本是否有意義在本地記憶體中，還是在每次更新時保存所有內容更好，因為磁碟畢竟便宜？

請在上下文中說明這不是我有過的經驗；我已經閱讀過有關聯接、規範化與非規範化表等的資訊，但我沒有這方面的實踐經驗。我處理了非常大的數據集，但在非 SQL 上下文中，這是我第一次來這裡，所以我希望這個問題提供了所需的資訊：D

我不是對你的問題投反對票的人，所以我不能代表那個人發言，但我的猜測是因為你的問題有點抽象和羅嗦，這個網站通常是針對更直接和具體措辭的問題，那是反對者的推理，因為有點不清楚你的目標是什麼/你在問什麼。話雖如此，我同意在沒有解釋的情況下被否決是很煩人的，所以相反，你有我的讚成票，因為你的問題足夠公平。🙂

無論如何，我能說的是，你的數據大小聽起來對 PostgreSQL 來說無關緊要。快速計算表明，按照您提到的新數據的速度，您在 10 年的時間跨度內仍將有不到 50 億條記錄。我什至不會太擔心記憶體，因為您的對象相當小（因此表中的單行不是很寬並且會很小）。

如果您的Token對象和TokenLiquidity對象具有一對一的關係，那麼將它們規範化為兩個表或將它們非規範化為一個實際上並沒有太大關係，因為您不會有數據冗餘，並且行/表不會通過將它們組合到一張表中，總大小不會增長太多，因此也不必擔心。

如果關係 fromToken是一對多，TokenLiquidity那麼情況就不同了，因為您最終會Token在表的多行中重複屬性，如果其中一個屬性的值發生變化TokenLiquidity，這會使管理變得更加困難。

我個人推薦的唯一一件事是，因為它在結構上才有意義，是有第三個單獨的表專門用於儲存表的歷史記錄，LiquidityToken而且專門只儲存Token0Amount,Token1Amount和Address（也許還有一個用於記錄whenDateTime的基礎欄位）欄位以最小化數據冗餘/最大化規範化。這將確保您的表盡可能輕巧，並且也使表的連接盡可能高效。歷史表只會在需要時加入，如果你有這個欄位，只在需要的時候加入。LiquidityToken``Token``DateTime

引用自：https://dba.stackexchange.com/questions/289886