爲什麼在運行時創建表（後面的代碼）很糟糕？

人們建議應該避免動態地（或者在運行時）創建數據庫表，並且這種說法是不好的做法，並且很難維護。爲什麼在運行時創建表（後面的代碼）很糟糕？

我看不出原因，也沒有看到創建表和任何其他SQL查詢/語句（如SELECT或INSERT）之間的區別。我編寫了在運行時創建，刪除和修改數據庫和表的應用程序，到目前爲止我沒有看到任何性能問題。

任何人都可以解釋在運行時創建數據庫和表的缺點嗎？

2011-05-14 KMC

這是一個有趣的話題，但我不認爲它是針對SO的討論。然後再次，其他人可能會認爲這是相關的... – 2011-05-14 04:17:08

@Mitch：我恭敬地不同意。數據建模通常是開發人員的職責，因此程序員而不是DBA。我認爲，除非有一個專門用於數據建模的SE站點，否則這個問題在這裏更適合，而不是其他任何現有的SE站點。 – 2011-05-14 04:30:18

表是比行更復雜的實體，並且管理表創建比必須遵守現有模型（表）的插入要複雜得多。誠然，表格創建語句是標準的SQL操作，但取決於動態創建它們會導致糟糕的設計決策。

現在，如果你只是創建一個或兩個，那就是它，或者動態地或整個數據庫，或者從一個腳本創建一次，那也可以。但是，如果您依賴於創建越來越多的表來處理數據，則還需要越來越多地參與並越來越多地進行查詢。我使用動態表創建的應用程序遇到的一個非常嚴重的問題是，單個SQL Server查詢只能涉及255個表。這是一個內置的約束。（這就是SQL Server，而不是CE）。在生產中只花了幾周的時間才達到這個限制，導致無法正常運行的應用程序。

如果您要編輯表格，例如添加/刪除列，那麼你的維護頭痛變得更糟。還有一個問題就是將你的db數據綁定到你的應用邏輯。另一個問題是升級生產數據庫。如果一個數據庫動態增長對象並且突然需要更新模型，這將是一個挑戰。

當您需要將數據存儲在這樣一個充滿活力的方式的標準做法是利用EAV models。您有固定的表格，並且您的數據以行的形式動態添加，因此您的模式不必更改。當然有缺點，但通常認爲這是更好的做法。

來源

2011-05-14 04:17:56

您需要對「創建表格」的含義有所瞭解。

不允許應用程序控制表的創建和刪除的一個原因是，這是一個只能由管理員處理的任務。您不希望普通用戶有能力刪除整個表。

臨時表AR一個不同的故事，你可能需要創建臨時表爲您查詢的一部分，但你的基本的數據庫結構應該只能由具有權利這樣做管理。

來源

2011-05-14 04:17:11

我猜這張海報指的是代碼優先的方法，它正在獲得...實際上重讀我不是那麼肯定海報意味着代碼優先... – 2011-05-14 04:18:20

嗯，就是這樣。這個問題太模糊，不知道他的真正含義。如果它首先提到代碼，那麼這個問題就沒有意義了，因爲這是它的目的。 – 2011-05-14 04:21:13

KMC，

請記住以下幾點

如果你想添加或刪除列，你很多需要在代碼改變和編譯agian
如果什麼數據庫位置變化
如果您在後端創建架構，那麼不擅長數據庫的開發人員可以進行更改，DBA可以處理它。
如果您遇到任何性能問題，可能會很難調試。

來源

2011-05-14 04:18:06 kobe

有時，動態創建表並不是安全智能（Google SQL注入）的最佳選擇，並且使用存儲過程會更好，並且通過執行存儲過程在數據庫級別執行插入或更新操作在代碼中。

來源

2011-05-14 04:22:07

爲什麼在運行時創建表（後面的代碼）很糟糕？

回答

相關問題