.Net架構挑戰：易發生變化的Frankestein模型

Question

早上好！

我們一直在撓頭與在辦公室這個有趣的場景，我們很希望聽到你的想法和做法：

1. 我們有一個數據庫，它的模式是 容易更改-lets叫它 Prony - 。 （用於存儲配置參數 嵌入式設備。因此，如果嵌入式設備 傢伙需要一個新表， 屬性或關係爲 模型，他應該能夠適應 在一個簡單的方法架構-happens所以 經常 - ）。

2. prony需要一個web界面來創建/編輯其數據（一組簡單的CRUDs就足夠了）。

3. 我們必須包含 數據也需要加載到 設備，使得一些 轉換之後另一個數據庫 - 讓我們稱之爲這個 Oddy - （這它是由一個已經存在的 管理網絡生成的數據應用）。

4. 最後我們有特雷西，一個服務器，我們的數據庫和我們的嵌入式設備進行通信。 她應該自動適應自己，適應我們的dbs模式更改並將數據序列化到設備。

不錯的拼圖，不這麼認爲嗎？ ：）

---

我們目前的候選人：

• 拉迪：快速

  允許創建 普羅尼一些看法，使數據轉換從Oddy 。然後 使用DynamicData（或某些RAD 工具）創建/更新一個簡單的Web 界面普羅尼（這樣他就可以 甚至從未來的Prony諮詢transformated數據 ：）。關於 特雷西，她將​​需要重新編譯 更新她的DB模式（實體框架應該工作），並使用反射遞歸探索模式和序列化數據。

  缺點：

  • 我們將不得不重新編譯特雷西和普羅尼的Web界面。

你怎麼看候選人的？

任何想法？

Answer 1

處理產品發佈後不斷變化的數據模型的一種方法是全部或部分使用EAV Database Model數據庫設計。 EAV結構添加了行而不是列或表格，並允許更少頻繁的模式更改（或根本不需要）。

它確實帶有自己的一組注意事項，例如需要經常調整數據，但他們可以被管理。生產中有很多EAV dbs。

性能說明：人們經常擔心EAV的性能。我有很多EAV，EAV表運行的記錄超過1000萬條。讀取，插入，更新和刪除都很好。當你開始大量報告這種數據結構時，會遇到麻煩。在你的情況下，你正在存儲設備的配置信息。這不是無害或微不足道的，但我會說，數據庫的這部分聽起來像EAV的一個很好的候選人，因爲你的讀寫會受到限制，我猜你的報告需要簡單。