为什么在运行时（代码隐藏）创建表是不好的？

Question

人们建议应该避免动态创建数据库表（或者，在运行时），并说这是不好的做法并且很难维护。

我没有看到原因，我没有看到创建表和任何其他SQL查询/语句（如SELECT或INSERT）之间的区别。我编写了在运行时创建，删除和修改数据库和表的应用程序，到目前为止，我没有看到任何性能问题。

任何人都可以解释在运行时创建数据库和表的缺点吗？

Answer 1

表是比行更复杂的实体，管理表创建比必须遵守现有模型（表）的插入要复杂得多。没错，表create语句是一个标准的SQL操作，但依赖于动态创建它们会产生糟糕的设计决策。

现在，如果您只是创建一个或两个，即它，或动态创建整个数据库，或者从脚本创建一次，那可能没问题。但是，如果您依赖于创建越来越多的表来处理数据，您还需要越来越多地加入并查询越来越多。我使用动态表创建的应用程序遇到的一个非常严重的问题是单个SQL Server查询只能涉及255个表。这是一个内置的约束。 （那就是SQL Server，而不是CE。）只需要几周的时间就可以达到这个限制，导致应用程序无效。

如果你开始编辑表格，例如添加/删除列，然后您的维护头痛变得更糟。还有将db数据绑定到应用程序逻辑的问题。另一个问题是升级生产数据库。如果数据库已经动态地与对象一起增长并且您突然需要更新模型，那么这将是一个挑战。

当您需要以这种动态方式存储数据时，标准做法是使用EAV models。您已经修复了表，并且您的数据会动态添加为行，因此您的架构不必更改。当然有缺点，但通常被认为是更好的做法。

Answer 2

KMC，

请记住以下几点

1. 如果要添加或删除列，您需要更改代码并将其编译为agian
2. 如果数据库位置发生变化，该怎么办
3. 不太擅长数据库的开发人员可以进行更改，如果您在后端创建架构，DBA可以处理它。
4. 如果遇到任何性能问题，可能很难调试。

Answer 3

您需要更清楚地了解“创建表格”的含义。

不允许应用程序控制表创建和删除的一个原因是，这是一项只应由管理员处理的任务。您不希望普通用户能够删除整个表。

临时表是一个不同的故事，您可能需要创建临时表作为查询的一部分，但您的基本数据库结构应仅由有权这样做的人管理。

Answer 4

有时，动态创建表并不是安全性最好的选项（Google SQL注入），使用存储过程会更好，并且通过在代码中执行存储过程，可以在数据库级别进行插入或更新操作。