按使用模式划分应用程序数据库是否有优势？

Question

我正在开发一个应用程序，它有两个不同的受众，因此有两种不同类型的数据。一方面，有非常高读/低写的元数据。这些表的行数相对较少，并且主要由应用程序的另一端读取。

应用程序的另一端基于非常高写入/低读取的事务性数据。这里会有大量的数据，而且在插入物上会有相当高的速度。应用程序的这一部分将从元端读取一些数据，但不会向该端写回任何内容。

在这两个表存储桶之间不需要任何RI。

我的问题是:为这些非常不同类型的数据创建两个单独的数据库有意义吗？这两种方法的优点和缺点是什么？

如果重要的话，这是使用SQL Server2008后端在.NET中构建的。

Answer 1

我建议花点时间确保这种设计不会阻碍将来的这种分离，而是将其作为单个数据库来实现。

这似乎是过早优化的味道。有很多高性能的数据库服务器可以在高负载下表现得同样好。尽管如此，仍然有一些复制解决方案，可以作为具有自定义数据复制的多个服务器来完成，或者通过光纤访问相同的物理存储的后端数据。

我认为，通过在项目实现的早期避免这种情况，您将节省大量可能不必要的工作。但是不需要很长时间就能预见到将来可以实现的方法(通过类设计、三层架构，甚至是数据库存储过程(icky) )。

Answer 2

根据您的描述，听起来您有两个截然不同的服务(从面向服务的软件的角度来看)。SOA的主要承租者之一是，您的服务应该是自治的，但是，只要您的服务背后有一个共享的数据库，就很难实现自治。您在描述中多次提到数据非常不同，并且应用程序彼此之间非常独立。这是一个很好的迹象，表明您在可以被认为是两个不同的服务之间有了明确的分离边界，每个服务都应该有自己的数据库来提高自主性。您可以让高写入/低读取服务使用高读取/低写入服务，或者，您可以让高读取服务定期向任何订阅者(即高写入服务)发布更改，每个订阅者将在自己的数据库中本地缓存所需的数据。

在Udi Dahan的视频中可以找到这种面向服务的设计的一个非常好的描述：http://www.vimeo.com/5022174。它可能有助于你解决你的问题。

Answer 3

我同意Kieveli的观点，但我想补充的是，由于高读取表的行数较低，您可以考虑缓存这些数据，以避免对数据库的大多数命中(初始化和刷新陈旧缓存除外)。

通过适当的设计，分离用于缓存的数据访问层应该有助于在将来需要时更容易地将其移动到不同的数据库。