为什么在运行时（代码隐藏）中创建表不好？
人们建议应避免动态（或在运行时）创建数据库表，认为这是不好的做法并且难以维护。
我不明白为什么，也没有看到创建表和任何其他 SQL 查询/语句（例如 SELECT 或 INSERT）之间的区别。我编写了在运行时创建、删除和修改数据库和表的应用程序，到目前为止，我没有看到任何性能问题。
任何人都可以解释在运行时创建数据库和表的缺点吗？
People suggest creating database table dynamically (or, in run-time) should be avoided, with the saying that it is bad practice and will be hard to maintain.
I don't see the reason why, and I don't see difference between creating table and any another SQL query/statement such as SELECT or INSERT. I wrote apps that create, delete and modify database and tables in run time, and so far I do not see any performance issues.
Can anyone explane the cons of creating database and tables in run-time?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
表是比行复杂得多的实体，管理表创建比必须遵守现有模型（表）的插入复杂得多。诚然，表创建语句是标准 SQL 操作，但依赖于动态创建它们会让人觉得是一个糟糕的设计决策。
现在，如果您只创建一两个数据库，或者动态创建整个数据库，或者从脚本创建一次，那可能就可以了。但是，如果您依赖于创建越来越多的表来处理数据，您还需要连接越来越多的数据并查询越来越多的数据。我在使用动态表创建的应用程序时遇到的一个非常严重的问题是单个 SQL Server 查询只能涉及 255 个表。这是一个内置的约束。 （那是 SQL Server，而不是 CE。）生产中只花了几周时间就达到了此限制，导致应用程序无法运行。
如果您开始编辑表格，例如添加/删除列，那么您的维护问题会变得更加严重。还有将数据库数据绑定到应用程序逻辑的问题。另一个问题是升级生产数据库。如果数据库随着对象动态增长并且您突然需要更新模型，这确实是一个挑战。
当您需要以这种动态方式存储数据时，标准做法是使用 EAV 模型。您有固定的表，并且您的数据作为行动态添加，因此您的架构不必更改。当然也有缺点，但它通常被认为是更好的做法。
Tables are much more complex entities than rows and managing table creation is much more complex than an insert which has to abide by an existing model, the table. True, a table create statement is a standard SQL operation but depending on creating them dynamically smacks of a bad design decisions.
Now, if you just create one or two and that's it, or an entire database dynamically, or from a script once, that might be ok. But if you depend on having to create more and more tables to handle your data you will also need to join more and more and query more and more. One very serious issue I encountered with an app that made use of dynamic table creation is that a single SQL Server query can only involve 255 tables. It's a built-in constraint. (And that's SQL Server, not CE.) It only took a few weeks in production for this limit to be reached resulting in a nonfunctioning application.
And if you get into editing the tables, e.g. adding/dropping columns, then your maintenance headache gets even worse. There's also the matter of binding your db data to your app's logic. Another issue is upgrading production databases. This would really be a challenge if a db had been growing with objects dynamically and you suddenly needed to update the model.
When you need to store data in such a dynamic manner the standard practice is to make use of EAV models. You have fixed tables and your data is added dynamically as rows so your schema does not have to change. There are drawbacks of course but it's generally thought of as better practice.
KMC，
请记住以下几点
KMC ,
Remember the following points
您需要更清楚“创建表”的含义。
不允许应用程序控制表创建和删除的一个原因是，这是一项只能由管理员处理的任务。您不希望普通用户能够删除整个表。
临时表则不同，您可能需要创建临时表作为查询的一部分，但您的基本数据库结构应该仅由有权这样做的人员管理。
You will need to be a little clearer about what you mean by "creating tables".
One reason to not allow the application to control table creation and deletion is that this is a task that should be handled only by an administrator. You don't want normal users to have the ability to delete whole tables.
Temporary tables ar a different story, and you may need to create temporary tables as part of your queries, but your basic database structure should be managed only by someone with the rights to do so.
有时，动态创建表并不是安全方面的最佳选择（Google SQL 注入），最好使用存储过程，并通过在代码中执行存储过程来在数据库级别进行插入或更新操作。
sometimes, creating tables dynamically is not the best option security-wise (Google SQL injection), and it would be better using stored procedures and have your insert or update operations occur at the database level by executing the stored procedures in code.