NHibernate SchemaUpdate 在生产代码中安全吗？答案

【问题标题】：Is NHibernate SchemaUpdate safe in production code?NHibernate SchemaUpdate 在生产代码中安全吗？
【发布时间】：2010-01-14 16:49:20
【问题描述】：

为简单起见。我在运行时将 Fluent NHibernate 的 Automapping 与 NHibernate 的 SchemaUpdate 结合使用。每次运行时，Automapper 都会为所有实体类创建映射，并且 SchemaUpdate 将架构应用到现有数据库。我很惊喜地发现它也能在空数据库上正常工作。到目前为止，它在开发环境中运行良好，让我能够相当快地响应错误。

我的问题是它是否足够可靠以留在生产代码中。显然，它不需要每次在生产环境中启动程序时都运行，但它对于增量产品更新很有用（尽管我不打算在产品发布后对域进行任何重大更改）。

（也许我真正的问题应该是结合使用这两个工具有多安全？）

更新

该应用程序有两个版本：独立桌面和多用户客户端/服务器。此外，由于业务领域（税务软件）的性质，我每年都可以从一个干净的数据库开始。

【问题讨论】：

感谢 CatZ 和 Greg Beech 提出安全问题。我没有考虑到这一点。我大部分时间都花在了安全性不太重要的独立桌面版本上。

标签： nhibernate fluent-nhibernate production-environment

【解决方案1】：

为了能够在生产代码中运行，生产应用程序用来连接到您的数据库的帐户必须有权更改数据库架构。

无论 NHibernate 代码的质量/可靠性如何，仅此一项就应该阻止您使用这种方法。

【讨论】：

【解决方案2】：

我不会冒险。行之有效的方法是在已从生产中恢复的登台服务器上运行它，然后使用数据库比较工具（例如 Red Gate）检查更改并生成脚本。

【讨论】：

【解决方案3】：

您可能需要考虑 SchemaUpdate 将始终进行附加和非破坏性更改，从而导致陈旧的列和可为空的列，而它们应该是不可为空的。

换句话说，绝对不能用于生产。

【讨论】：

那么有什么好的选择呢？某种类型的迁移？您会为此推荐任何好的 .net 框架吗？谢谢

【解决方案4】：

这取决于数据的重要性！我怀疑这对银行系统来说是个好主意。除了一件事，我对更新没有任何问题。有时它不能正确重命名。此外，与可以像这样修改架构的帐户连接存在安全风险:)

【讨论】：