有哪些策略可以與開發人員團隊維護通用數據庫架構而沒有DBA？

Question

我很好奇其他人如何在沒有DBA的情況下解決了許多（10+）開發人員維護和同步數據庫更改的問題？ 我的意思是，基本上，如果有人想要對數據庫進行更改，那么采取哪些策略呢？ （即我已經創建了一個'Car'模型，現在我想將適當的DDL應用於數據庫等。）

我們主要是一個Python商店，我們的ORM是SQLAlchemy。 以前，我們用這樣的方式編寫了我們的模型來使用我們的ORM創建模型，但是我們最近放棄了這個模型，因為：

• 我們無法使用ORM跟蹤更改
• ORM的狀態與數據庫不同步（例如，主要與索引和唯一約束相關的許多差異）
• 除非開發人員通過電子郵件向團隊記錄數據庫更改，否則無法審核數據庫更改。

我們解決這個問題的方法是基本上有一個“看門人”，他檢查數據庫中的每個更改，並將所有接受的數據庫更改應用於accepted_db_changes.sql文件，從而需要進行任何數據庫更改的開發人員將他們的請求放入proposed_db_changes.sql文件。 我們檢查這個文件，並且，當它更新時，我們都將更改應用到我們的開發機器上的個人數據庫。 我們不在模型上創建索引或約束，它們明確地應用於數據庫。

我想知道維護數據庫模式的一些策略是什么，如果我們看起來合理的話。

謝謝！

Answer 1

解決方案是管理然后技術:)

一般規則很簡單，項目中應該只有樹狀依賴： - 應始終有一個主模式源，與項目源代碼一起存儲在版本控制中 - 受主變更影響的一切每次更新主源時都應自動重新生成源，如果自動生成不起作用，則不允許手動干預 - 修復主源或生成器，不要手動更新源代碼 - 所有重新生成應該由更新主源的同一人執行，包括主源更改在內的所有更改都應視為單個事務（單個源控件提交，每個受影響環境的單個構建/部署，包括DB更新）

強制執行，可獲得100％可靠的結果。

主源有3種可能的選擇1）DB元數據，通過連接到實時DB的某些工具在DB更新后生成源2）源代碼，一些工具從源生成SQL方案，以特殊方式注釋和然后SQL運行在DB 3）DDL上，SQL模式和源代碼都是由某些工具生成的4）使用了一些其他描述（比如由生成SQL模式和源代碼的特殊Perl腳本讀取的文本文件）

1,2,3同樣好，只要你需要的工具存在並且不會過於昂貴4是一種通用方法，但它應該從項目的最初開始應用，並且有幾千行代碼的開銷。一種奇怪的語言來維持

Answer 2

您是否嘗試過SQLalchemy Migrate工具？

它們專門用於自動遷移數據庫設計更改。

Answer 3

假設您直接在物理數據庫上設計數據庫，那么我是否正確？ 多年前我曾經這樣做，但結果db的質量非常差。 如果您使用建模工具（我個人認為Sybase pdesigner仍然是最好的，但環顧四周）每個人都可以對模型進行更改，並根據需要同步他們的本地數據庫（它還將獲取文檔任務）。 所以，重新bobah的帖子，主人是pdesigner模型而不是物理數據庫。

你的accepted_db_changes.sql文件是一個龐大的更改腳本列表嗎？ 我不確定我是否喜歡更改文件名等的想法。鑒於兩個db版本之間的區別是alter scripts的順序列表，如何模型如下：

Ver1 (folder)
  Change 1-1.sql
  Change 1-2.sql
  Change 1-3.sql
Ver2 (folder)
  Change 2-1.sql
  Change 2-2.sql
  Change 2-3.sql

在提交之前審查每個更改（新文件）的位置。

一般規則應該是盡可能地在dev環境中自動執行盡可能多的db部署; 我們在這項工作上獲得了可觀的投資回報率。 您可以使用像redgate這樣的工具來生成您的ddl（它有一個api，但不確定它是否適用於SQLAlchemy）。 IMO，數據庫更改應該是微不足道的，如果您發現它們正在阻塞，那么請查看您可以自動執行的操作。

Answer 4

您可能會發現重構數據庫這本書很有用，因為它包含管理數據庫的一般策略，而不僅僅是如何折射數據庫。

他的系統期望每個開發人員都擁有自己的數據庫副本以及部署到生產之前使用的一些通用測試數據庫。 您的情況是本書中描述的一種較簡單的情況，因為您沒有使用數據庫的許多單獨的應用程序（盡管您確實需要知道如何描述數據庫遷移的人）。 最重要的是能夠從源代碼控制中的信息構建數據庫，並通過小型遷移（參見@ WoLpH的答案）描述更改，而不僅僅是在數據庫中進行更改。 如果您至少有ORM < - >數據庫測試來檢查它們是否仍然同步，您也會發現更容易的事情。