從備份策略的角度來看，在同一個應用程序中使用關係數據庫（如 MySql）和麵向文件的數據庫（如 MongoDB）是否有效？

我正在開發一個應用程序，我需要為任何給定實體儲存不確定數量的屬性，例如：

 Entity    || # of properties**
 Apples    ||  14
 Oranges   ||  4
 Pears     ||  12

使用關係數據庫，我可以為每個實體設置一個主鍵，並擁有與屬性一樣多的行，但是，據我所知，只有在屬性的數量是固定的並且事先知道的情況下，我才能考慮這種方法，但在這種情況下，可能會有少至 0 屬性或多至 99.999 的行，所以我最終會有很多，nulls因此我正在考慮建立一個面向文件的 APP (MongoDB) 模組來解決這個問題和它會如下：

{
 'Apple':{'Property1','Property2','Property3','Property4',...},
 'Orange':{'Property1','Property2','Property3','Property4',...}
}

我打算通過主鍵關聯這兩個數據庫，但我不確定混合兩種類型的數據庫是否是一個好主意，因此是個問題。

在應用程序的正常日常操作中，這將是可以的。將有第二個客戶端庫和連接語法包裹在某處的數據層中，業務邏輯甚至不會注意到。

您最大的問題將是保持兩個數據儲存之間的一致性。您不太可能同時擁有一個事務覆蓋並送出或回滾兩者。因此，您最終可能會遇到不一致的情況。如果您可以建構應用程序，使其可以寫入一個數據庫，送出，然後寫入另一個數據庫，那麼您就可以了。

類似的問題是備份和災難恢復。每個 DBMS 都有自己的備份和恢復機制。不可能為兩者生成一致的備份，或者將兩者都還原到單個時間點。恢復後協調兩者將是一個手動過程。

該應用程序還將增加網路流量，因為它必須將消息發送到兩個不同的後端以檢索一個邏輯實體。這可能並不重要，具體取決於查詢速率、延遲和對延遲的敏感性。

更好的解決方案可能是將動態屬性儲存在一個長字元串中（如果查詢不需要檢查這些屬性的值），使用 MySQL 內置的 JSON 功能，或者實現某種形式的表繼承。

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