泪奔 求关于MSSQL的设计思路

[ichinaec]

我目前在设计一个小项目，项目有不同的产品，不同的产品有数量不一的用户群体，比如有些产品只有几百，上千用户群体，我原来规划是用多台数据库服务器来存明细，将明细(关注的用户列表)的数据放在别的数据库服务器，而一台数据库服务器存多个产品，然后我在主数据库服务器上，放一个表，用来指示每个产品ID它所对应的所在的明细服务器。那么问题来了，有个别产品，它的用户群体是上亿级别的，这样的话，一台服务器也可能都存不下更别说一张表（因为还涉及到一些较复杂的统计哦，所以不能单表放这么多条记录，更新也会非常的慢）。
求助希望有经验的朋友们提供思路。

[以专业开发人员为伍]

我们有一个产品，老板说他联系好某省的一个处长，很快就会有几百万（有一定规模的）用户。结果呢？连5个用户都没有。 你先说说你有没有长期维护过文件总量超过200G的小数据库吧。如果没有，那么你就一步一步来，不要动不动就说你的数据库会爆。真正影响性能的是你的设计，而不是数据库尺寸大小。

[ichinaec]

引用 1 楼 sp1234 的回复:

我们有一个产品，老板说他联系好某省的一个处长，很快就会有几百万（有一定规模的）用户。结果呢？连5个用户都没有。 你先说说你有没有长期维护过文件总量超过200G的小数据库吧。如果没有，那么你就一步一步来，不要动不动就说你的数据库会爆。真正影响性能的是你的设计，而不是数据库尺寸大小。

嗯嗯，没有200G，也就是90G左右，我没有太过关注文件的大小，因为如果数据很大，可以分表存储。 求设计思路，因为有一些产品的用户群体少，可以规定一个范围之内的产品，放在某台数据库服务器的某个表，但也有过亿的情况发生，类似这种的话，也可以分表，就是需要分好多个，例如5个，或是好几个，字段数量是比较多的。如果同一个产品的用户放在几个表里，那么当需要查询某个用户的时候，就可以好几个表都要查了，如果我按照客户ID来做MD5后取第一个字符来定位放在哪个表的话也可以，但也有其他不仅仅只是根据客户ID来进行的查询。我总觉得这样也不合理。

[ichinaec]

引用 1 楼 sp1234 的回复:

我们有一个产品，老板说他联系好某省的一个处长，很快就会有几百万（有一定规模的）用户。结果呢？连5个用户都没有。

你的意思也是考虑的一个范围，可是从立项来说，会有一个需求的预期。预期在设计阶段就需要，而至于结果如何，属于第二阶段的事情了，我想表达的意思是，咱们想的一样，规划和现实会有不一致的情况，另外，在没有办法的时候，也可以先做力所能及的范围，碰到真的有这样的增长的时候，那去考虑进一步的解决方案。