應對模式演變的策略？

Question

目前，我們在Data-Access對象中使用手動滾動的SQL，並使用大量的存儲過程和觸發器，這些存儲過程和觸發器的數量約爲20k行代碼。我們發現簡單的修改會導致幾天的修復工作，並導致最終期限的下滑。

變化包括修改表，以應付增加的數據的基礎上，QA /用戶報告的模式等，其多數民衆贊成在建，以取代舊的東西和緩慢的一個非常活躍的系統的整體重構。

我們看着可嘗試並限制這些變化的影響的PHP ORM解決方案，但他們應對我們的模式是太慢了; 「簡單」的sql結果比我們的自定義查詢返回的時間要長得多，並導致〜.5s的頁面訪問超過20秒。

我可以看看，以應對與關係數據庫架構演變，在一般情況下有哪些最佳實踐/策略？

編輯：忘了提及有關觸發器;我們有很多依賴級聯變化的數據，例如。價格變化在這裏爲這個用戶更新了價格有爲該用戶等

Answer 1

你可能想簽上Refactoring Databases: Evolutionary Database Design這本書。

Answer 2

我的建議是擺脫存儲過程，而使用內聯SQL，可能保持在文本/ XML文件。我發現SProcs維護起來更煩人和費時。一旦生成查詢計劃（第一次執行查詢），您會發現性能差異可以忽略不計。另外，你將能夠版本控制你的整個DB腳本...

Answer 3

我建議使用連續（或至少每晚）構建策略。
在每次簽到時重建數據庫，或者至少每天一次。
也是每天一次，運行單元測試來運行每一位代碼，無論是存儲程序，觸發器還是數據訪問層。

有一個很大的成本，以書面形式存儲的特效，但是這會立即識別符。
一旦你知道休息的地點，你可以修復它。

我很想聽聽其他人對這個策略的經驗適用於數據庫變更。

Answer 4

我們使用Enterprise Architect作爲我們的數據庫定義。我們包含存儲過程，觸發器以及在UML中定義的所有表定義。該計劃的三大亮點是：

1. 從ODBC連接導入UML圖。
2. 一次爲整個DB生成SQL腳本（DDL）
3. 生成DB的自定義模板化文檔。

作爲一名開發人員，我在10多年裏從未對任何其他工具印象深刻。 EA一舉支持Oracle，MySQL，SQL Server（多個版本），PostGreSQL，Interbase，DB2和Access。任何時候我遇到問題，他們的論壇都會及時回答我的問題。強烈推薦！！

在DB的變化來了，我們做那麼在EA，生成SQL，並檢查它到我們的版本控制（SVN）。我們使用Hudson建築，當它看到你已經修改了檢查的SQL它自動建立從腳本到數據庫中。

Answer 5

這裏是我的建議：

1. 試圖擺脫的最少使用的功能。質疑未被使用的功能。應用程序中的每個功能都與其相關的幾個成本級別（維護，支持，迴歸測試，代碼複雜性等）。
2. 存儲過程望而卻步，除非有絕對沒有辦法有效，並在代碼中的可擴展的方式做到這一點。
3. 逐步引入的ORM溶液（使用重構從JDBC移動到ORM），以減少在CRUD操作的代碼和代碼複雜度的量
4. 生成功能，集成和單元測試，當你修正錯誤並把這些測試連續集成系統。儘可能多地自動執行迴歸測試，以便在簽入時立即發現問題。
5. 一般情況下，當你修正錯誤，利用這個機會來重構解耦實現/代碼模塊。

如果您有關於數據庫遷移問題的問題，這可能幫助：http://shashivelur.com/blog/2008/07/hibernate-db-migration/