为什么在运行时创建表（后面的代码）很糟糕？

人们建议应该避免动态地（或者在运行时）创建数据库表，并且这种说法是不好的做法，并且很难维护。为什么在运行时创建表（后面的代码）很糟糕？

我看不出原因，也没有看到创建表和任何其他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

为什么在运行时创建表（后面的代码）很糟糕？

回答

相关问题