多个客户共享同一个数据库的设计办法

顶！我也在考虑同样的问题。有没有在实际项目中使用的同学介绍下经验。

共用一个表、共用一个库或各用一个库，都有各自的优劣处，根据情况决定吧

叶伟的那本SAAS的书有简单介绍，楼主可以参考一下。

这两天在网上发现了这家公司的http://www.xtools.cn/已经做成了.而且客户都已经快过万了.他们是做CRM的.这项目如果真要做成功的话,客户数达到几千,或者1W,共用一个项目,共用一个数据库,这可真让人怕怕啊. .

云计算平台不就是解决这个问题的吗？理论上讲，客户根本不知道自己的数据在一个还是多个数据库中。

共用一套应用代码，支持分布式，每个商户一个数据库的方式，无从是从硬件成本还是维护成本，应该算是最佳的方案了。

像这种应用一般单个用户数据量不大，可以使用mongoDB，每用户创建一数据库，用户验证数据独立存储，这样的话性能、用户自定义字段、性能、水平扩展都不是问题。曾经问过mongoDB技术人员，他说每个mongoDB实例维护数万个数据库不成问题。

关于客户独立应用的问题就不要考虑了，否则成做项目了，成本过高

一个客户一个库，那显然不是太好的解决方式。
如果要做，底层肯定是分布式的存储，考虑水平和垂直的分库，备份之类的事情
中间做好路由
上层做好权限控制。

我去看过了，也是CRM，国内还有个八百客，据说也是做的不错。只是不知道技术实现上是否也采用一个应用，多个schema来处理。

我个人认为：
小客户应该是可以不用单独分离数据库，采用共用数据库，添加标示来区分各自的数据；
中型客户可以采用分schema来处理；
大型客户可以分库，分应用，毕竟还是有定制化的需求。
其实这么说不太客观，不好做客户分类，如果单从用户数，数据量来分？如果定位到这三种模式同时都支持，系统的实现难免复杂。

支持分布式是指应用吗？每个商户一个数据库，如果小商户使用的人不多，数据量也不多，利用率不高啊。不知你们公司的客户规模怎样？

公司是做餐饮ERP的.客户也就是餐饮企业,数据也就是餐饮企业每天的采购记录这些吧.一家客户一天1000条记录,几百个客户的话,也就几十W数据吧,没处理过大数据量,对这不清楚...