如果每次 API 呼叫時都不存在，則創建表：不好的做法？
我正在用 MySQL 作為 Web 應用程序的數據庫在 PHP 中編寫一個簡單的 API。我打算
CREATE TABLE IF NOT EXIST在每個 API 呼叫中放置所有表。我希望我會有 5-6 張桌子。
我這樣做的原因很簡單：我不需要任何額外的腳本來執行應用程序的初始化——它會在第一次執行時自動執行。
作為一個缺點，我希望這會減慢 API 操作。但是我嘗試記錄 API 呼叫，它仍然是 2-3 毫秒（在我的情況下，如果有 CREATE TABLE，我沒有註意到任何區別）。
有什麼想法嗎？
所以讓我們向前思考一點。應用程序上線，創建了表格，一切都很可愛。然後，您有一個新要求，並且表必須更改。你怎麼編碼？有用於程式碼從未執行的環境的 CREATE，以及用於現有環境的一堆 ALTER。現在出現了另一個要求。這次您必須出於某種原因遷移數據。現在有 CREATE（用於新環境）、ALTER（用於現有環境）和一大堆 DDL 和遷移邏輯。但是等等 - 還有更多。出於非常好的業務原因，您希望保存遷移數據的列與現有列具有相同的名稱。您現在如何判斷數據庫是否已遷移？您不再有僅元數據查找。不，
是的！你是一個巨大的成功。無數人想要使用您的服務。風險資本家將大量資金推到您家門口。第三方組織正在乞求與您合作。開發團隊的規模增加了一倍（不，三倍！），以處理商業機會和定制。哎呀。這些都必須在 API 啟動程式碼中進行編碼。每個。和。每一個。一。您不再擁有 API。您擁有所有遷移腳本之母，並附加了一段業務程式碼。：悲傷的臉：
出於同樣的原因，我正在搜尋成本資訊。**可能沒有成本，因為表通常被記憶體並且不會有磁碟訪問。**數據庫的瓶頸通常是磁碟訪問。但是，也許更好的解決方案將具有以下功能：
- 您必須有版本表來跟踪數據庫版本。如果你不這樣做，在某些時候你會遇到麻煩。
- 您必須為前一個版本中的每個版本以及所有已發布版本的列表具有遷移腳本/功能，以便您可以以相同的順序從目前數據庫版本到 api 版本執行它們。
- 可能有一個主遷移腳本，它將呼叫每個版本的腳本。此腳本可以在目標應用程序測試中執行，而不是在 api 呼叫中。在我看來，在沒有監控的情況下更新數據庫是一個壞主意。一個好的應用程序會有一些測試——例如單元測試、selenium 等。
- 遲早您會到達無法自動更新數據庫的地步，因為您插入了無法填充預設值並需要數據的新列/表。這就是為什麼必須監控更新。您拋出了一個描述性非常強的異常，它說明了必須做什麼以及指向文件的連結，其中包含對遷移過程的更詳細描述。應用程序開發人員製作遷移腳本，執行它，然後再次執行 API 遷移腳本。
- 由於 4 中描述的手動步驟可能需要位於遷移腳本的中間，因此您可以為每個遷移腳本設置遷移步驟。遷移步驟可以寫入版本表。這樣，更新腳本可以檢查它處於哪個階段，並在下次執行時檢查是否已完成手動步驟並從離開的地方繼續。
聽起來很複雜，但這就是編寫 API 和編寫應用程序之間的區別。除非您的應用程序必須安裝在許多伺服器上…
此外，如果您設計得好，您將不必進入複雜的步驟。每個版本更新腳本都是一個步驟，主要是添加可能具有預設值的新表或欄位。如果你設計得非常好，大多數版本更新根本不需要更新數據庫。