数据库用户的最低要求是什么，我看到的所有教程都使用sa帐户。出于安全考虑，我宁愿不使用此帐户。
我已在本地部署了1.10.2分支的开发版本，并将dbowner角色应用于它们，但我再次不希望在生产中执行此操作。
这实际上取决于您希望应用程序的用户（包括站点管理员）能够做什么。 Orchard中最有特权的用户需要能够创建和更改表（当他们创建新的内容类型，安装模块，运行迁移等）时，这几乎需要dbowner。还要记住，它是作为特定db用户连接到数据库的应用程序。对于不同的应用程序用户（甚至角色），您不会获得不同的数据库用户。
然而，想要设置一个过程，其中应用程序的最危险功能将在生产中的数据库级别被禁止，并且仅允许在分段中使用数据库部署机制，这是完全合理的。从dba的角度来看，这尤其有意义。
然而，对于大多数站点而言，这比看起来更棘手，因为生产数据库很少是只读业务（因为注释，用户创建的内容等）。这意味着这个部署过程需要比将staging DB推入prod更加微妙。这甚至没有提到这样做的复杂性，同时最大限度地减少了停机时间。
我见过的另一个解决方案是设置两个指向同一数据库的Orchard实例，并使用两个具有不同权限的不同数据库用户。公共权限有限，甚至没有部署管理模块，管理实例位于防火墙后面，具有所有权限和功能。然而，这是一个非常不寻常的设置，你必须权衡风险与实用性（毕竟，使用CMS的主要好处是使管理员能够轻松地改变网站的内容，所以任何与之相反的事情都会减少好处）。
大多数Orchard网站更喜欢使用dbowner设置，假设如果应用程序遭到入侵，数据库也会受到损害并不一定会更糟。