2010-07-24 67 views
9

團隊在數據庫上工作有什麼更好?它是每個開發人員或共享數據庫的本地數據庫實例嗎?使用數據庫的最佳實踐團隊

+0

它取決於如何設計數據庫模式(如果設計的話),測試數據的複雜程度,數據庫模式的穩定程度以及內容。隨着發展的進行可能會有所不同。 – pascal 2010-07-24 09:23:34

+0

什麼是BD?這是一個數據庫的錯字,還是我沒有聽說過的產品? – 2010-07-24 09:30:35

+0

我發現這篇文章: http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx 但我同意「pascal」它取決於數據庫大小,模式和其他特徵。 – k0stya 2010-07-24 09:40:07

回答

12

根據我的經驗,團隊應該有(至少)一個用於整合的共享數據庫。

在開發過程中,每個團隊成員應該有一個獨立的數據庫,否則數據庫模式的變化可能會阻礙其他團隊成員。這些實例也可能位於中央服務器上。

1

根據經驗,共享數據庫更好。我們的代碼常常被打破,因爲有人在本地數據庫中添加了一列,然後將他們的新源代碼上傳到SVN。然後其他人的實現將會中斷,直到他們發現數據庫中發生了什麼變化。

我會有一個共享的數據庫進行開發。我們還有一個或兩個開發數據庫也用於其他測試。

+0

在另一種情況下,如果某人更改了數據庫中的列類型並且沒有上傳ORM模式? – k0stya 2010-07-24 09:55:11

+1

我們以相同的方式處理應用程序代碼和DB代碼(存儲過程,模式更改)。我們確實有偶爾忘記的數據庫更新,但開發人員很快就知道,當我們確定有問題的代碼時,他們寧願不要在他們面前發現雞蛋,因爲持續集成和測試並不難。我們有一條規則,您需要在簽入和編寫針對數據庫的自動化測試之前編寫升級腳本。 – aqwert 2010-07-25 23:12:20

4

我只能談的方式,團隊我目前的工作是,這符合我們的需求不夠好:

我們有一個自動更新任何數據庫的最新架構的版本一箇中央數據模型腳本。開發人員檢查對該腳本的更改以及對源代碼的更改(同一存儲庫上的單一提交)。每晚構建更新一箇中央數據庫副本,隨後對該數據庫進行一批自動化測試,而人類QA團隊第二天也會使用同一個數據庫進行所有測試。

除了通過集成構建之外,我們不允許以任何其他方式對中央數據庫實例進行架構更改。爲了開發模式更改腳本,可以在中央服務器上或在本地(取決於個人偏好)在單獨的數據庫實例上開發更改。

4

我不認爲它完全取決於。每個環境應該有它自己的數據庫實例。就個人而言,我絕不會推薦團隊中的每個人都在同一個源代碼副本上工作,並且我以同樣的方式查看數據庫代碼和實例。

如果您在更改數據庫時發生問題,這是不同開發過程問題的症狀。忘記將代碼文件添加到源代碼管理將會非常不方便。

Jeff Atwood has a pretty good article on source controlling database code.

不同的開發者在不同的問題理應工作 - 你如何避免踩到別人的腳趾,而單元測試?

我絕對主張通過Continuous Integration process進行更新的集成/測試環境。這個環境也經常作爲您部署過程的試金石。

3

在Redgate,我們建議每個開發者都有自己的實例,因爲沙盒確保開發者不會踩在彼此的腳趾上。但是,這兩種模式都有優點和缺點。

根據我們與數據庫開發人員交流的經驗,大約有一半的數據庫開發是在共享環境中執行的,一半是在專用的每個開發人員環境中執行的。

1

爲開發人員提供獨立的數據庫實例可以幫助他們隔離工作,但是如果我們是一個龐大的團隊並在同一時間處理多件事情,那麼最好還是共享一個環境,以便所有需要的更改在同一時間交付並沒有打破對方,他們的依賴也可以正確計算出來。這也有助於確定任何應用程序可能由於更改而中斷的地方。所以最好有一個共享的環境以及開發環境的一些單獨的環境副本,以防萬一我們想要測試一些非常重要且需要工作的大而複雜的東西。

但唯一的問題是保持多個環境相互同步,因爲任何遺漏的變化都可能是致命的。

+0

是的,擁有獨立的數據庫*和*「集成」測試的共享環境顯然是理想的選擇,如果您仔細考慮,這就是持續集成提供的。開發人員應該在單獨的沙箱上進行開發,將其更改提交到源代碼管理,這會觸發持續集成,從而構建和測試包含所有更改的數據庫。 – 2011-09-17 09:06:02

1

我知道這裏的人是根據他們過去的經歷來講的,但這並不是一個普遍回答的簡單問題。每種方法都有優點和缺點,應根據您正在使用的應用程序和團隊的類型加以解決。

如果您不知道要走哪條路..我建議先與共享的開發數據庫一起查看是否遇到任何問題。如果此解決方案有效,它應該是首選方法,因爲它消除了「集成」步驟。但是,根據團隊類型和環境需求,您可能需要適應。