我刚刚开始指定一个项目，该项目将是一个相当高级的数据库，具有相当简单的 MVC 前端，可通过 Internet 访问，我不确定如何处理用户，我可以看到两个选项：
选项 1 - 使用 SQL Server 内置登录名/用户来处理用户身份验证，并使用内置用户访问权限来控制谁可以访问什么（几乎所有内容都将是选择或存储的过程）。
选项 2 - 使用我自己的用户列表（带有散列加盐密码）和我自己的访问控制列表（可能使用 proc 名称并OBJECT_NAME(@@PROCID)传递给另一个 proc）并通过应用程序配置文件对数据库进行所有写入/读取，并访问所有程序/意见。
我已经搜索但找不到任何理由我应该选择一个而不是另一个，任何人都可以分享一个链接或提供一个比另一个更好的原因（或者如果两者都有明显的问题）？
如果您需要更多详细信息，请告诉我。
如果通过连接池使用 SQL 身份验证（每个用户的选项 1），您将获得相对较差的性能。您将为每个用户获得池，但这仍然可能意味着 100 或 1000 的连接。有一些方法可以解决这个问题，但解决方案开始让选项 1 像选项 2 一样工作，所以你不妨使用选项 2。
我已经看到一些解决方案创建 SQL 帐户来为每个用户进行初始身份验证（通过基于单个应用程序的 SQL 帐户），然后其余的像选项 2 一样工作（再次通过基于单个应用程序的 SQL 帐户）。这些案例使用了大量的 SQL 帐户，因此每个用户都可以拥有一组视图，并模仿 Schema。由于 Schemas & Aliases 自 SQL Server 2005 以来一直可用，因此不再值得选择选项 2。
最后，也不要使用 SQL Server 应用程序角色——它们是不好的安全实践。Brian Kelly 在一篇关于它们的文章 ( http://www.sqlservercentral.com/articles/Security/sqlserversecurityprosandconsofapplicationroles/1116/ )中介绍了一些问题（正反两面）。