在 NoSQL 和關係數據庫之間進行選擇，同時具有靈活性和一致性要求
我從來沒有專業地使用過數據庫，只是玩弄了使用小型 sqlite db 為我自己的音樂收藏進行數據庫編碼。現在我被要求為多個使用者建構一個內部數據庫系統。在基本閱讀了 NoSQL 與關係數據庫之後，我想對如何選擇正確的技術有一些想法。
語境
- 在此數據庫之前，使用者完全使用電子表格。
- 這些工作表的結構（架構）因項目而異。
- 有時同一個項目有幾個不同的工作表需要隔離，但仍然存在於同一個數據庫中。
- 我們希望將所有這些工作表導入數據庫，並在不破壞原始電子表格的情況下添加新欄位並即時更新舊欄位名稱/值
- 當發生原始碼控制操作時，我們希望能夠連接到數據庫並更新有關原始碼控制管理狀態的某些欄位
- 該數據庫將由來自不同位置的各種使用者使用，目前全部通過內部網路。不會有很多使用者喜歡在 Facebook 或 Twitter 上。
- 所有數據都必須本地化為多種語言，並且最好在同一個數據庫中共存。
問題
- 既然我們將有不同的工作表結構，那麼 NoSQL 是不是比關係數據庫更好的選擇？
- 使用者將繼續使用電子表格，並可能隨時更改其工作表結構。這對於 NoSQL 或 SQLite 等關係型數據庫來說會不會很麻煩？
- NoSQL 不支持關係型數據庫的 ACID，是否意味著多個使用者在同一條記錄上工作時數據可能會損壞？我們通常想要一致性。
- 如果我們維護一個優化的數據庫，但仍希望能夠將選定的部分或全部導出為 CSV 或 JSON 文件？NoSQL 或關係會更好地工作嗎？
- 如果我們線上進行，如何從頭開始處理訪問控制？這會影響數據庫技術的選擇嗎？
- 對於這種類型的系統，我們應該聘請數據庫專家開發和/或維護人員嗎？我們能否在一些需要最少後端/前端、安全技術研發的免費/開源基礎設施上進行建構？
感謝您提前輸入！
直接回答您的問題：
- “既然我們會有不同的工作表結構，那麼 NoSQL 是不是比關係數據庫更好的選擇？ ”
A. 可能不會，除非這些表結構中的每一個都作為一個應用程序緊密相關，它們都將儲存在相同的幾個表中。否則，聽起來您只有一系列結構化數據集（多個應用程序），每個數據集都可以用自己不同的表集來表示。這是很正常的，可以很容易地在關係數據庫管理系統 (RDBMS)或NoSQL數據庫中實現，因此這裡沒有區別。 2. “使用者將繼續使用電子表格，並且可能會即時更改其工作表結構。這對於 NoSQL 或 SQLite 等關係數據庫來說會不會很麻煩？ ”
A. 保存到數據庫的數據是電子表格的消費者嗎，即除了寫入數據庫之外，電子表格是否還需要從數據庫中讀回？如果是這樣，那麼無論您使用哪種類型的數據庫，都需要處理更改結構，問題只會出現在應用程序的不同層。使用RDBMS，您需要一個流程來管理在客戶端發生的數據庫中的模式更改，否則您的數據庫將不會儲存輸入的任何新數據。使用NoSQL數據庫，您的問題存在於另一個方向，當將數據拉回客戶端的新模式時，但來自NoSQL的數據實例仍然過時，與客戶不匹配。使用 Excel，它實際上可能更寬容，只是將這些列留空。但請記住，如果您選擇將數據分佈在多個節點上， NoSQL中的****一致性也會有所不同。它最終是一致的，這意味著如果來自較新結構的數據尚未復製到另一個節點，則電子表格的一個使用者可能會收到與同一電子表格的另一個使用者不同版本的架構。更多關於你下一個問題的答案。 3. “ NoSQL 不支持關係型數據庫的 ACID，是不是意味著當多個使用者在同一條記錄上工作時數據可能會損壞？我們通常希望一致性。 ”
A. NoSQL遵循BASE 原則（並受CAP 定理約束），這意味著與遵循ACID原則的****RDBMS不同，它最終是一致的。這意味著對數據庫的更改，包括數據本身的更改，不能保證立即復製到分佈該數據庫的所有節點上。但它最終將在所有節點上複製並保持一致。關於您的問題，這並不意味著如果您使用NoSQL數據庫與RDBMS相比，數據更有可能被損壞（從系統的角度來看）並且多個使用者正在更改同一記錄。相反，它只是意味著同一記錄可以在不同節點之間同時處於多個不同狀態，直到最後一次（通常）更改在該數據庫的所有節點之間變得同步，以便最終變得一致。RDBMS通常採用具有鎖定機制的算法來確保一致性是即時的，並且同一記錄一次不會處於多個狀態。 4. “如果我們維護一個優化的數據庫，但仍希望能夠將選定的部分或全部導出為 CSV 或 JSON 文件？NoSQL 或關係會更好嗎？ ”
答：在高層次上，我相信您不會發現兩者之間有任何區別。對於這兩種類型的數據庫系統來說，這是一個同樣可以實現的目標，並且當您進入它時，差異將是非常低級的細節。一些RDBMS本身支持將數據儲存和/或導出為JSON和CSV格式，並且通常NoSQL數據庫已經將數據儲存（或檢索）為JSON，並且應該有方法通過這些數據庫的現代實現將結果轉換為CSV 。 5. “如果我們線上進行訪問控制，如何從頭開始處理？這會影響數據庫技術的選擇嗎？ ”
A. “線上操作”是指基於雲的解決方案嗎？如果是這樣，從安全的角度來看，這不應該改變任何事情。無論哪種方式，所有現代數據庫系統都可以直接在數據庫系統本身中設置帳戶或映射到另一個安全系統。例如，Microsoft SQL Server 數據庫系統提供了為數據庫創建專用登錄或利用Active Directory的能力，這樣您就可以在****Windows 使用者和組之上定義數據庫內的訪問控制，即使在使用 Azure（微軟的雲解決方案）來託管您的數據庫。類似的想法也適用於其他現代數據庫系統。 6. “對於這種類型的系統，我們是否應該聘請數據庫專家開發和/或維護人員？我們可以建立在一些需要最少後端/前端、安全技術研發的免費/開源基礎設施上嗎？ ”
答：聽起來你有很多問題，並且想圍繞你計劃解決的問題做一些事情，所以如果可能的話，僱用具有豐富數據庫經驗的人（尤其是同時使用RDBMS和NoSQL的人）將是只對你有益。目前，根據您提供的資訊並根據您提出的問題，我客觀地認為沒有任何區別因素可以選擇一種類型的數據庫系統而不是另一種類型的數據庫系統。我唯一的主觀意見是使用RDBMS，因為聽起來您的數據至少是結構化的（即使它確實發生了變化 - 這在RDBMS中很好），並且如果NoSQL的最終一致性可能是您的案例的問題。如果您正在尋找開源和免費的RDBMS，那麼我建議您研究 PostgreSQL。