我正在开发一个具有两个不同受众的应用程序，因此有两种不同类型的数据。一方面，存在非常高读取/低写入的元数据。这些表的行数相对较少，主要由应用程序的另一端读取。
该应用程序的另一面基于非常高写/低读取的事务数据。这里会有很多数据，插入速度也很快。应用程序的这一部分将从元端读取一些数据，但不会将任何内容写回到该方。
这两个表格之间不需要任何RI。
我的问题是：为这些非常不同类型的数据创建两个独立的数据库是否有意义？这两种方法有哪些优点和缺点？
如果重要，则使用SQL Server 2008后端在.NET中构建。
答案 0 :(得分：1)
我建议花时间确保设计在将来不会妨碍这种分离，但要将其作为单个数据库实施。
闻起来过早优化。有许多高性能数据库服务器可以在高负载下同样良好地运行。即便如此，仍有复制解决方案，可以作为具有自定义数据复制的多个服务器，或通过光纤访问相同物理存储的后端数据。
我认为通过在项目实施的早期避免这种情况，您将节省大量潜在的不必要的工作。但是，不需要花费大量时间来预测将来可以实现的方法（通过类设计，3层架构，甚至是数据库存储过程（icky））。
答案 1 :(得分：0)
根据您的描述，听起来您有两种不同的服务（从面向服务的软件的角度来看。）SOA的主要租户之一是您的服务应该是自治的，但是自治很难实现，所以只要你有一个共享数据库。您在描述中多次提到数据非常不同，并且应用程序彼此非常独立。这是一个很好的迹象，表明您可以将两个不同的服务分开，这些服务应该各自拥有自己的数据库来提高自主性。您可以让高写/低读服务消耗高读/低写服务，或者，您可以让高读服务定期向任何订户（即高写服务）发布更改，每个这将在他们自己的数据库中本地缓存他们需要的数据。
Udi Dahan在此视频中可以找到关于此类面向服务设计的非常好的描述：http://www.vimeo.com/5022174。它可能有助于您解决问题。
答案 2 :(得分：0)
我同意Kieveli，但是想补充一点，因为高读表的行数很少，你可以查看缓存这些数据以避免数据库上的大多数命中（除了初始化和刷新过时的缓存）。
如果需要，可以使用合适的设计将数据访问层分离出来，以便将来更容易将其移动到其他数据库。