您是否在实际应用程序中使用SchemaExport和SchemaUpdate？最初，你创建模型，然后生成架构？它工作吗？或者，您只用于测试...NHibernate和代码优先
通常，我使用设计器创建数据库（使用Visual Studio数据库项目），然后创建映射和持久化类或EF实体。但是现在，我想用Fluent NHibernate尝试第一种代码方法。
我研究了SchemaExport和SchemaUpdate，发现了一些问题。例如，update不会删除数据库对象，如果存在表，则不会创建非空列（如可为空），也不会在多对多表上生成主键等等。这意味着我必须经常重新创建db。但是，数据是什么？并且，如何部署更改生产分贝等...
我想知道你真的先在代码中使用代码，然后使用SchemaExport（SchemaUpdate）吗？可能你可以给我一些建议...
我在生产中使用SchemaUpdate。正是因为它从不进行像删除列这样的破坏性操作，所以很安全。但是，它不是更新数据库的全面解决方案。如果你使用它，你仍然需要用脚本来补充它，以更新你的模式来完成删除操作（如你所提到的），索引，改变列类型，添加表格数据等。但SchemaUpdate覆盖了90％的情况。
我发现的唯一缺点是，随着时间的推移，它似乎偶尔向我的表添加重复的外键约束。
还有一件事：您应该从构建工具手动运行SchemaUpdate，而不是您的应用程序本身。这是不安全给你的应用程序修改你的数据库架构的权利！
是的，你可以在实际应用中使用它们;我做。
当然，几乎所有的工作都是先发生。我的做法是创建一个单独的项目，引用我的主项目程序集中的映射，并处理数据库创建和初始数据导入（如果有的话）。
一旦项目投入生产，我通常会从解决方案中卸载该项目，但保留该项目以供参考，或者需要从创建脚本切换到更新脚本。
至于NHibernate创建数据库的方式，你必须在你的Fluent映射中做更多的规范。我喜欢指定null/not null，外键约束名等，以最大限度地控制数据库的创建方式。
我不认为你会想在这种情况下使用automapping。
我使用SchemaUpdate/SchemaExport来快速演化我的模型，但它们不是数据库迁移工具的替代品。正如你所提到的，在很多情况下，数据不能以合理的方式迁移。该工具没有足够的上下文。 （例如，如何自动将FullName列迁移到FirstName/LastName？）我在这里回答了一个类似的问题，在这里我讨论了NHibernate环境中的db迁移工具。
NHibernate, ORM : how is refactoring handled? existing data?
只是任何生成代码，无论是从工具或数据库生成在你的问题POCO的产生，它可能会得到你的方式出现80％。从那里调整其他20％是明智的，以增加你的索引和任何其他性能调整，让它恰到好处。