將大量（10000多種）DIFFERENT對象類型存儲到數據庫中的最佳做法是什麼？

Question

在設計新的關係數據庫時，通常每個對象類型都由相應的表格表示。設計一個數據庫的最佳實踐是，哪個數據庫存儲大量的DIFFERENT對象類型，以避免創建和維護數千個數據庫表？對於這種情況，關係數據庫有哪些更好的替代方案？

Answer 1

使用NoSQL數據庫（Lucene的，蒙戈，卡桑德拉，Solr的，彈性的搜索，Hadoop的，等），存儲文件，可以有任意數量的字段（想想鍵/值映射）。在關係數據庫方面，就像每個「行」可以有不同的行定義。過去我已經實現了這一點，並且我發現它很方便地存儲一個class字段，所以我可以重建正確類型的對象（在我的情況下是Java，但適用於任何語言）。

您也可以使用支持JSON列類型的關係數據庫（例如Postgres），並將您的對象序列化/反序列化到/來自JSON並將它們存儲在JSON類型的列中。爲了創建一個方便的單表解決方案，您可能需要一個存儲對象類型的列來簡化反序列化。我也實現了這個選項，它對我很有幫助。

兩種選擇都很好。第一個是更好的技術。如果您已經熟悉RDBMS，則第二個可能不那麼神祕。

---

你做什麼不想要做的就是使用任何對象關係數據庫解決方案，其中每個對象類型都有匹配類字段列的專用表。如果你改變了班級的定義，並且如果不同班級的數量增長超過一個非常小的數字，這完全是不確定的。

Answer 2

答案很大程度上取決於數以千計的對象類型之間的區別的本質，以及它們可以被分類和進一步推廣到什麼程度和以何種方式。在這種情況下，發現是可維護設計的關鍵。

以下是一些可能適用於您的對象類型集的潛在持久性選項。需要考慮每個人的利弊。

1. 查詢一個隱藏的結構或模式中的對象類型允許它們被分解^1,2,3。
2. 發現可以應用（1）的對象類型的類別。
3. 將多個對象映射到單個或更少的一組表或文檔類型。
4. 一對一映射對象並確定一個元方案來保持它們的價格合理。

無論數據庫是否爲關係數據庫，結構如何，可用的搜索功能類型以及如何實現密鑰都應該在上述發現之後作出的決定。這是最佳做法。

確定存儲，維護和檢索具有所需特性的數據結構無法在500頁的書中充分回答，因此當然不是簡短的答案。

瞭解這些潛在選擇的利弊將是一個好的開始。您可以通過網頁搜索這些持久性哲學的名稱和「數據庫」或「持久性」來查看相應的描述和供應商產品。

• 關係表
• 關聯對象
• 片狀非關係
• 映射（鍵和值）
• 映射（鍵和固定記錄有效載荷）
• 文獻（自由文本）
• 分層
• 圖（連接頂點的邊的網絡）
• 多維（OLAP等）

你可能會發現你有成千上萬的數據類型的原因是，它們所對應的文件類型，並在共同它們之間的唯一的一點是，他們都寫在或人類語言甚至可能不是這樣。也許它們是任意的語言環境，在這種情況下，國際化的文檔存儲系統是首先要檢查的選項。

您可能會發現有10,000多種對象類型中的9,800個語義規則可以確認，在這種情況下，規則的表徵和規範可能會導致更細粒度的存儲方案^4,5,6。將語義結構與結構化軟件設計項目（比如組合或裝飾模式）結合起來可能會大大減少對象類型的數量。

這樣的重構很容易就值得花時間，並且可能讓您的項目在很短的時間內加快速度。

發現附加結構後，您需要確定哪些規範化級別對您的存儲，更新，檢索和磁盤空間要求有意義。

關於規範化和反規範化的文獻（遍佈網絡）將幫助您瞭解空間，寫作速度和閱讀速度之間的取捨^7,8.9。如果每天存儲大量數據，則ETL特性也將顯着地應用到設計中。

供應商和產品的選擇可能是您在開始低級別設計和實現以及測試框架構建之前在體系結構上所做的最後一件事情。 （這是如此多的數據類型的另一個挑戰，你將如何充分測試10,000多個類？）

如果沒有更多關於數千種對象類型的特性以及爲什麼會有這麼多的特性，那麼給出比這更狹義的建議將是不負責任的。

---

參考

[1] https://www.tutorialspoint.com/design_pattern/design_pattern_quick_guide.htm

[2] https://sourcemaking.com/design-patterns-and-tips

[3] https://sourcemaking.com/design_patterns/strategy

[4] https://www.cs.cmu.edu/~dunja/LinkKDD2004/Jure-Leskovec-LinkKDD-2004.pdf

[5] https://archive.org/details/Learning_Structure_and_Schemas_from_Documents

[6] https://www.researchgate.net/publication/265487498_Machine_Learning_for_Document_Structure_Recognition

[7] http://databases.about.com/od/specificproducts/a/Should-I-Normalize-My-Database.htm

[8] http://www.ovaistariq.net/199/databases-normalization-or-denormalization-which-is-the-better-technique/#.WLOlG_ErLRY

[9] https://fenix.tecnico.ulisboa.pt/downloadFile/3779571831168/SchemaTuning.ppt

Answer 3

「最佳實踐」 是主觀的，且通常作爲一種呈現個人偏好的方式，以某種方式具有權威性。

所以，這是我的個人偏好...

你必須做分析工作。你的數據是否有關係？你能否說有實體和關係？如果是這樣 - 創建一個關係模式。您可能不得不處理繼承關係 - 這是傳統關係模型不能很好地處理的問題，但有一些可能的solutions。

您討論的對象是不是真正的關係？他們有不同的屬性，還是主要由非結構化數據組成？這些關係主要是分層的嗎？你真的在談論時間序列數據或地理對象嗎？在這種情況下，您可能會被許多NoSQL解決方案之一提供更好的服務。

數據是「讀寫」還是「只讀」？您是否正在構建一個用於報告和分析的大數據存儲庫？如果是這樣，您可能需要使用OLAP/BI數據庫解決方案，而不是關係架構。

您是否有極高的可擴展性或性能要求？如果是這樣，在哪裏 - 讀，寫，分析？如果是這樣，你可能需要考慮一個高度非規範化的數據模型。

Answer 4

敢肯定，當你說10000+對象類型，它超越了原始的類型，如整型，浮點等，甚至複雜的已知類型的圖表等

不能使用關係型數據庫作爲存儲例如簡單的圖形將需要設計自定義關係和表格。所以，唯一的選擇就是使用鍵值 NoSQL數據庫，其中任何對象類型將被序列化到文件，並存儲在對象ID

Answer 5

不管數據庫的類型，你可以考慮一個替代方案是存儲你的數據是一個JSON字符串。這樣存儲的數據可以根據需要動態變化，並且可以自由更改。其缺點包括僅限於服務器端和客戶端JSON處理程序，它們將完成查詢，解析和其他相關數據的所有「繁重」工作。

像其他人一樣說NoSQL數據庫聽起來像你正在尋找避免關係數據庫的結構要求方面。

Answer 6

區分對象類型，對象要素，對象屬性和對象實例。

沒有系統應該有10,000+個對象類型。維護這樣的源代碼將是可怕的。相反，確定如何擁有10到100個對象類型，並使用特徵和屬性來模擬那些不同的事物。

即使您先從實體關係圖或設計開始（從後端向前設計），您應該將數據類型數量限制爲100，並提供規範化或非規範化的模式以表示屬性，功能以及您的分解的物體。

你不妨看看software design patterns來獲得一些想法。