如何正確管理複雜的數據庫結構？

假設您有多個系統使用相同的數據庫 - 每個系統使用多個方案（有時與其他方案相同）。這些方案的這種結構有點大而複雜。如何正確管理複雜的數據庫結構？

現在，你怎麼可能管理這樣的方案結構？顯然，使用某種「配置」 - 最簡單的就是SQL腳本，但更合理的解決方案是可以輕鬆轉換爲SQL或其他可讀解決方案（例如，JPA的XML或註釋）的XML。

儘管這個解決方案導致了一個問題，即您無法確切地知道您的配置是否完全匹配數據庫結構。你不能說這兩個是否同步。他們爲什麼不呢？那麼，在這樣一個龐大的結構中，將會有很多改變，並且在改變方案之後，你不會永遠記得保存/提交你的配置，或者你確實保存/提交了它，但最終沒有改變計劃中的任何內容並忘記取消對配置的更改。

不僅如此，另一個問題（不是由配置引起的，而是由它來解決）是版本控制。我沒有看到管理DB方案版本的好方法（比如說我們最後的修改會導致3個系統崩潰 - 不好，如何「回滾」？）。

想法？謝謝。

來源

2010-06-11 Eyal Roth

這個問題很模糊，但我相信LiquiBase（www.liquibase.org）是爲了解決你所描述的問題。

來源

2010-06-11 21:06:08

簡要閱讀了這個庫之後，它似乎有助於管理版本控制（也在幾個開發者之間），但是它如何處理同步問題呢？該庫可以查看我的配置並查看數據庫方案，並告訴我它們之間有什麼區別，甚至可以生成能夠像現在一樣反映數據庫結構的配置？ – 2010-06-11 22:38:14

是的。有點。數據庫本身會跟蹤哪些更新日誌已經運行，並能夠根據其現有模式生成更改日誌：http://www.liquibase.org/manual/generating_changelogs。 – 2010-06-12 00:10:20

雖然有工具可以檢查兩個數據庫之間的差異，但這些使用這些工具來促銷產品是非常危險的。通常還有物體還沒有準備好發送到產品，一個工具將無法知道這一點。這種情況更可能發生在由多個不同應用程序使用的大型企業類型數據庫中。

數據庫代碼應該像其他代碼一樣對待。它應該在腳本中進行源代碼管理，並按照發行版進行組織。沒有適當版本的源代碼控制腳本，沒有什麼可以推動的。

來源

2010-06-15 21:31:05 HLGEM

如何正確管理複雜的數據庫結構？

回答

相關問題