为什么在运行时(代码隐藏)中创建表是不好的

本文关键字：创建运行时代码隐藏为什么 | 更新日期: 2023-09-27 17:56:38

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

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

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

表是比行复杂得多的实体，管理表创建比必须遵循现有模型（表）的插入要复杂得多。诚然，表创建语句是标准的 SQL 操作，但依赖于动态创建它们有点糟糕的设计决策的味道。

现在，如果您只创建一两个，仅此而已，或者动态创建整个数据库，或者从脚本创建一次，那可能没问题。但是，如果您依赖于必须创建越来越多的表来处理您的数据，您还需要越来越多的联接和查询。我在使用动态表创建的应用程序时遇到的一个非常严重的问题是，单个 SQL Server 查询只能涉及 255 个表。这是一个内置约束。（这是SQL Server，而不是CE。在生产中仅用了几周时间就达到了此限制，导致应用程序无法正常工作。

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

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

KMC ，

记住以下几点

如果要添加或删除列怎么办，则需要更改代码并再次编译
如果数据库位置发生更改怎么办
不太擅长数据库的开发者可以做出改变，如果你在后端创建模式，DBA可以处理它。
如果您遇到任何性能问题，则调试可能会变得困难。

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

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

临时表

则不同，您可能需要创建临时表作为查询的一部分，但基本数据库结构应仅由有权管理的人员进行管理。

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