EF Interitance and DBA Concerns

對於一個新項目，我們的應用程序開發人員希望使用Entity Framework的每種類型表繼承模型。EF Interitance and DBA Concerns

我們最近向我們的DBA展示了這個功能和產生的表模式，他表達了擔憂，我想知道如何解決它們。繼承是面向對象的一個重要組成部分，從開發角度來說，讓DB和ORM本身支持這個概念是非常好的。這個功能是EF的一部分，所以它不像我們將設計拉出左邊的領域。

他的主要問題是：

我們不使用存儲的特效
增加的複雜性將使報表和數據更新困難

我們已經差不多解決了存儲過程擔憂（並且我們現在已經使用另一個ORM 3年了）。

至於複雜，我看到他的觀點，但counterpoints解決這些問題（對我來說）：

報告不應從事務表（我們目前做到這一點）執行，意見或應該使用轉換後的報告數據庫。
更扁平結構的數據更新仍然會弄亂數據 - 更新數據的人員有責任瞭解結構。 EF的table-per-type繼承模型使用的模式並不複雜，但在進行手動更新時必須遵守。

我知道我們不是第一個遇到DBA關注的數據庫支持模型繼承。其他人如何說服他們的DBA這是一個很好的模型？

來源

2011-05-26 Bret Walker

我應該補充一點，我希望有一種方法來強制繼承模型與數據庫級約束。 EF永遠確保數據的正確插入/更新是非常好的，但我不喜歡這樣一個事實：在數據庫層面沒有任何東西可以確保數據的完整性。也就是說，我不確定沒有使用低效的手動編碼的觸發器或類似的東西可以做到這一點。我錯了嗎？ – 2011-05-26 13:36:04

針對視圖進行報告仍然最終會觸及事務處理表。但是，您聲稱應該針對轉換後的報告數據庫執行報告是正確的。 – datagod 2011-05-26 13:37:10

你是對的。我應該說對交易模式報告，而不是表格。 – 2011-05-26 13:44:23

他的主要擔憂是沒有考慮TPT的實際問題。

如果需要，可以將存儲過程與TPT結合使用。
數據更新並不難。 EF將處理它們並確保數據修改的正確順序。

TPT的主要問題是inefficient queries（檢查評論以及）。 EF中的TPT存在實際性能問題，因爲即使不需要派生表中的數據，也會產生大量左連接和聯合。創建這個數據結構的任何報告並通過EF訪問報告數據是非常糟糕的決定。

編輯：

如果他的關切涉及與數據庫工作的其他工具，那麼他們完全合法的，但在同一時間，它只是你的數據庫結構的正確的文件。

來源

2011-05-26 13:43:20

也許這並不清楚，但我指的是更新完成的SQL語句和通過其他工具（如SSRS）完成的報告。英孚在他關心的任何一個領域都沒有發揮作用。 – 2011-05-26 13:46:17

EF Interitance and DBA Concerns

回答

相關問題