NHibernate SchemaUpdate 在生产代码中安全吗？
为了简单起见。我在运行时将 Fluent NHibernate 的 Automapping 与 NHibernate 的 SchemaUpdate 结合使用。每次运行时，Automapper 都会为所有实体类创建映射，而 SchemaUpdate 将架构应用到现有数据库。我很惊喜地发现它在空数据库上也能正常工作。到目前为止，它在开发环境中运行良好，并且使我能够相当快地响应错误。
我的问题是它是否足够可靠，可以留在生产代码中。显然，它不需要每次程序在生产环境中启动时都运行，但它对于增量产品更新很有用（尽管我不打算在产品发布后对域进行任何重大更改）。
（也许我真正的问题应该是结合使用这两个工具有多安全？）
更新
该应用程序有两个版本：独立桌面和多用户客户端/服务器。另外，由于业务领域（税务软件）的性质，我每年都有幸从一个干净的数据库开始。
For simplicity's sake. I'm using Fluent NHibernate's Automapping combined with NHibernate's SchemaUpdate during runtime. On each run Automapper creates mappings for all entity classes and SchemaUpdate applies the schema to the existing database. I was pleasantly surprised that it works correctly against an empty database as well. It's worked fine so far in a development environment and has allowed me to respond to bugs rather quickly.
My question is whether it is reliable enough to leave in production code. Obviously it doesn't need to run every time the program starts in a production environment but it would be useful for incremental product updates (though I don't plan on making any major changes to the domain after the product ships).
(Perhaps my real question should be how safe is it to use these two tools in conjunction?)
Update
The application has two versions: a standalone desktop and a multiuser client/server. Also due to the nature of the business domain (tax software) I have the luxury of starting with a clean database each year.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
为了能够在生产代码中运行，生产应用程序用于连接到数据库的帐户必须有权更改数据库架构。
仅此一点就应该阻止您采用这种方法，无论 NHibernate 代码的质量/可靠性如何。
For this to be able to run in production code, the account that the production application uses to connect to your database would have to have permission to change the database schema.
That alone should deter you from this approach, irrespective of the quality/reliability of the NHibernate code.
我不会冒险。有效的方法是在已从生产恢复的登台服务器上运行它，然后使用数据库比较工具（例如 Red Gate）检查更改并生成脚本。
I wouldn't risk it. What works well is to run it on a staging server that has been restored from production, then use a database comparison tool (such as Red Gate) to examine the changes and generate a script.
您可能需要考虑 SchemaUpdate 将始终进行附加和非破坏性更改，从而导致过时的列和可空的列（它们应该是不可空的）。
换句话说，绝对不用于生产用途。
You may want to consider that SchemaUpdate will always make additive and non-destructive changes, resulting in stale columns and nullable columns where they should be non-nullable.
In other words, absolutely not for production use.
这取决于数据的重要性！我怀疑这对于银行系统来说是个好主意。除了一件事之外，我没有遇到任何更新问题。有时它不能正确重命名。此外，与可以像这样修改架构的帐户连接存在安全风险:)
It depends on how critical the data is! I doubt that's such a good idea for a banking system. I have not had any problems with the update apart from one thing. Sometimes it does not rename properly. Further more it's a security risk connecting with an account that can modify the schema like that :)