为什么在运行时(代码隐藏)中创建表是不好的
本文关键字:创建 运行时 代码 隐藏 为什么 | 更新日期: 2023-09-27 17:56:38
人们建议应该避免动态创建数据库表(或者在运行时创建),并说这是不好的做法,很难维护。
我看不出原因,也没有看到创建表和任何其他SQL查询/语句(如SELECT或INSERT)之间的区别。 我编写了在运行时创建、删除和修改数据库和表的应用程序,到目前为止,我没有看到任何性能问题。
任何人都可以解释在运行时创建数据库和表的缺点吗?
表是比行复杂得多的实体,管理表创建比必须遵循现有模型(表)的插入要复杂得多。诚然,表创建语句是标准的 SQL 操作,但依赖于动态创建它们有点糟糕的设计决策的味道。
现在,如果您只创建一两个,仅此而已,或者动态创建整个数据库,或者从脚本创建一次,那可能没问题。但是,如果您依赖于必须创建越来越多的表来处理您的数据,您还需要越来越多的联接和查询。我在使用动态表创建的应用程序时遇到的一个非常严重的问题是,单个 SQL Server 查询只能涉及 255 个表。这是一个内置约束。(这是SQL Server,而不是CE。在生产中仅用了几周时间就达到了此限制,导致应用程序无法正常工作。
如果您开始编辑表格,例如添加/删除列,那么您的维护头痛会变得更糟。还有将数据库数据绑定到应用程序的逻辑的问题。另一个问题是升级生产数据库。如果数据库随着对象的动态增长而突然需要更新模型,这将是一个真正的挑战。
当您需要以这种动态方式存储数据时,标准做法是使用 EAV 模型。您有固定的表,并且您的数据作为行动态添加,因此您的架构不必更改。当然有缺点,但通常被认为是更好的做法。
KMC ,
记住以下几点
- 如果要添加或删除列怎么办,则需要更改代码并再次编译
- 如果数据库位置发生更改怎么办
- 不太擅长数据库的开发者可以做出改变,如果你在后端创建模式,DBA可以处理它。
- 如果您遇到任何性能问题,则调试可能会变得困难。
您需要更清楚地了解"创建表"的含义。
不允许应用程序控制表创建和删除的一个原因是,这是一项只能由管理员处理的任务。 您不希望普通用户能够删除整个表。
临时表则不同,您可能需要创建临时表作为查询的一部分,但基本数据库结构应仅由有权管理的人员进行管理。
有时,动态创建表在安全方面并不是最佳选择(Google SQL注入),最好使用存储过程,并通过在代码中执行存储过程在数据库级别进行插入或更新操作。