我有三个不同的应用程序，它们都共享数据库的ASP.NET成员资格方面，几乎肯定它们不会共享任何其他内容。
我是否应该为每个应用程序创建一个单独的数据库，还是一个就足够了？
所有应用程序表都带有前缀，因此在集成中不会出现问题。虽然我想知道是否会出现任何性能问题，或者如果让所有三个应用程序共享同一个数据库会出现某种严重错误。
有问题的应用程序是三个Web应用程序，“主站点”，一个论坛和一个bug跟踪器。我想知道这是否可行，因为如果我有一个数据库，集成可能会更容易。例如，错误跟踪器在其数据库连接中注册asp.net成员资格表，它甚至创建了一个“admin”用户，其中实际应该持有成员资格表的数据库将是“主站点”。 / p>
更新：我为这个问题添加了一笔赏金，因为答案似乎对于我是否应该将多个数据库用于仅共享成员资格提供者的不同应用程序存在相当分歧的意见。
答案 0 :(得分：16)
单独的应用程序=单独的数据库 - 除非您必须将所有内容“挤压”到一个数据库中（例如，在共享的Web主机上）。
答案 1 :(得分：12)
我一直觉得拥有更多数据库会更容易：
我实际上会选择四个数据库。成员资格数据库，然后每个应用程序一个（如果成员资格真正共享）。这样您就可以跨应用程序锁定安全性。
仔细看看你的问题......你说数据“可能不会被共享”...你的很多查询会加入会员表吗？如果是这样，如果它们位于同一个数据库中可能会更容易。但是，如果您使用更基于实体的方法，我认为您对多个数据库仍然会更好。您甚至可能希望为您的成员资格数据库查看类似LDAP数据库或其他类型的缓存，以加快速度。
答案 2 :(得分：5)
除非您当前需要将它们放在不同的数据库中，否则应该使用相同的数据库 - 但是，如果可能，您应该构建系统，以便在需要时将数据移动到单独的数据库中。
实际上，这意味着您应该保持SQL过程尽可能少地处理数据 - 即，没有多步存储过程可以执行大量单独的操作。有单独的usps并从代码中调用每个usps。
使用单独数据库的原因：
1）无关数据 - 相互关联的组数据 - 和数据库超出一定的复杂性，希望将相关数据块分离到单独的数据库中以简化。
2）应将更重要的数据（例如个人详细信息）分开，以便采取更大的安全措施：从开发人员那里筛选这些数据
3）或更低的重要性（例如，记录信息） - 这可能不需要备份 - 如果它特别庞大，您可能不希望它增加备份主站点数据库所花费的时间。
4）由居住在不同位置的不同服务器上的应用程序使用。很明显，您希望将数据尽可能地放在消费应用程序上。
如果没有真正了解系统的大小和规模，很难给出完整的意见，如果它只是你自己的网站，一个数据库现在可以工作 - 如果它是商业的那么我就有4个dbs来自go：Membership详情，论坛，Bug Tracker和MainSite相关的东西。
因此，在代码中，您将拥有一个会员管理器，它只与会员数据库，一个BugManager，一个ForumManager和其他任何内容进行通信，只会与MainSite数据库进行通信。我想不出你需要任何这些数据库相互交谈的原因。
答案 3 :(得分：4)
只是我的倾向：虽然这三个应用程序可能分享不多（不是尚未，但是当论坛帖子想要引用错误报告时会发生什么？），它们都属于同一个“系统，”可以这么说。
我肯定会将所有表放在一个数据库中。
答案 4 :(得分：1)
在我看来，最好分割数据库以提高灵活性，安全性，效率和可扩展性。
将来，如果对所有三个应用程序共同增加任何要求（您永远不知道），则可能有点难以维护。
例如：3个应用程序的用户登录/审计跟踪。
答案 5 :(得分：0)
这可能听起来像是在徘徊，但你是否考虑过另一种可能性，即将所有身份验证/成员身份功能分离到应用程序本身？
根据您的描述，您似乎可能会在将来添加其他应用程序。它将开始看起来像一个网站网络，就像37signals网络应用程序，谷歌网络应用程序或MSN网络应用程序。
因此，您可以选择单点登录/连接服务。这个单一的应用程序可以通过Web服务或任何其他机制提供身份验证方法，它将有自己的数据库供您调整，修改，备份和移动，而不会影响其他应用程序。我自己已经多次发现这种情况，因此我喜欢在应用程序中分享您的Google或Facebook登录是多么容易。
也许我从一个比你更高的角度看待它，对不起，如果是这样的话。如果这不是一个选项，您可以保留4个数据库：每个应用程序1个，成员资格提供者1个，大部分时间都有自己的连接字符串。
当然，这取决于应用程序在数据库级别上的占用空间大小。每个应用程序10个表是可以的，每个应用程序150个表会使数据库对我们来说有点难看，这是个人偏好。
祝你选择的任何选择好运。
答案 6 :(得分：0)
membership framework允许跨多个应用程序进行分区，因此您可能应该进行以下配置：
然后，在每个应用程序数据库中，创建指向成员资格数据库表的同义词，以便在需要编写自己的查询时访问应用程序数据和成员资格数据。同义词易于维护，允许您更改数据库的位置，而不会更改这些表的任何依赖关系，因为同义词名称不会更改。
您在Web.config中的应用程序配置将确定如何为成员数据库中的数据进行分区，因为您为每个应用指定了ApplicationName应该是不同的。