數據庫設計你有什麼想法
多年來，我一直在嘗試，現在正在考慮將其變成一個真正的項目。
我正在考慮開發一種位於 RDMS 之上的“驅動程序”（oracle、MSSQL、MySQL - 其他人可以效仿）。給定表描述，驅動程序創建儲存過程和客戶端程式碼範例（前端、後端等）。
最終結果將是極客將在上述任何 RDMS 中創建一個表，而我的程式碼將生成選定的客戶端介面。
例如輸入表定義。檢查一些按鈕並點擊一些按鈕，然後會出現一個 zip 文件，其中包含一個 Web 表單 .NET 項目，可以從給定的數據庫（或特定表）中添加/更新/刪除/選擇記錄。然後，開發人員可以獲取該程式碼並進行微小的更改（化妝品安全性）並使用它作為自己的。
美妙之處在於，如果開發人員想為 mysql 定義表，他們可以通過點擊按鈕更改為 MSSQL，並且之前生成的任何程式碼都將保持完整。
我意識到這是“程式碼審查”，我沒有程式碼。但是任何好的持久程式碼都要經過這個設計階段。
對這個概念有什麼想法嗎？
我很欣賞迄今為止的想法。我同意所說的大部分內容。選擇選項框並點擊按鈕後的傳遞物將不是“成品”。更重要的是，開發人員仍然需要使螢幕漂亮。如果有兩個表 tblOrders 和 tblOrderItems - 最終結果將是每個表的兩個“表格”。這對“使用者”來說並不理想，但對開發人員很有幫助。可傳遞成果的每一部分都需要一些開發人員/DBA 的“調整”。
程式碼生成器很棒！程式碼生成器是邪惡的！
10 到 15 年前，我會說擁有一個程式碼生成器來為數據庫驅動的應用程序快速創建樣板程式碼將是對人類的一份偉大禮物。
5-10 年前，我會說程式碼生成器很糟糕，它們生成了太多重複的程式碼，並且具有數據驅動的使用者界面（螢幕上的欄位、驗證等是由數據庫中的元數據驅動的逐個對螢幕進行編碼）將是取代程式碼生成器的偉大禮物。
今天我會說 - 單獨編寫每個螢幕。在執行簡單的 CRUD 時，使用連接欄位和模型對象的現有框架以及可能的 ORM。但請務必根據螢幕的確切用途設計每個螢幕。過多反映 RDMS 表的應用程序螢幕僅適用於管理查找表。不要用針對電腦儲存模型 (RDMS) 設計的極客界面來惹惱使用者……製作一個只有他們需要的螢幕。這可能意味著它將保存到多個表等。誰在乎呢。使用者不是數據庫。
所以我的想法？不要浪費時間製作程式碼生成器。
Erwin 有一種宏語言，用於編寫可針對 Oracle 或 SQL Server 編譯的儲存過程。恕我直言，您編寫醜陋的程式碼，其中的變數將被翻譯成特定數據庫引擎可以理解的東西，然後 Erwin 將為該數據庫引擎創建翻譯版本。我已經多年沒有與 Erwin 合作了，所以我不確定它是否仍然具有該功能。恕我直言，您為特定數據庫引擎開發數據庫和應用程序，以便您可以使用該數據庫的最佳功能來獲得最佳數據庫應用程序。