请教一个数据库的表问题,服务器是否能够承受压力,请进!!!!

[nightlocus]

偶现在正在打算设计一个数据库,业务层可能比较复杂了点,初步的设计是这样的:
所有的用户是使用同一个数据库服务器,但是使用是有限制的,可能来自5个或者10个人是一个团体单位的,他们之间的数据要实现共享.但是所有人所使用的数据库的表结构是一样的.来自用户的团队可能很多,上万吧.
我在想,给不同的团队都建立自己的数据表,但是如果团队多了,这样的表也要建立好几万个表吧,这样查询起来是不是速度会很慢呢?
另外呢,所有的用户使用同一个表,但是这样数据会更多,是不是更影响效率呢?
我再这两种方案中不能决策,有没更好的解决办法,望告知,不胜感觉.
我想知道一个sql server2000的数据库服务器的最大服务访问量和数据表的承受能力是多大?

[nightlocus]

谢谢各位的耐心解答,每个团队的数据之间的操作是紧密的,这个团队和另外的团队之间没有任何的关系.也就是每个团队之间是独立的,团队内部之间的访问数据是需要共享的.
那我觉得应该为每个团队都建立关系表.至于维护我不太明白如何需要维护呢?对每个表的操作都是很常见的,基本的舔加,删除,查询等操作,我想没 必要要存储过程吧.

[nightlocus]

对于一个团队,我想数据流量每天每个团队的的记录也就是20个就够多了,没个团队内部有5台计算机,如果要上2000个团队的访问的话,服务器要承受的访问量并发的上限就是1万.1万个并发的处理我想对服务器来说应该是小菜,关键是怎样设计数据库合理,以及怎么构架系统.我采用的是b/s架构.

[bugchen888]

分表是肯定的了,不明白楼主还想问什么....

[zjcxc]

每个团队的数据都不相关? 那应该是分库了,每个团队一个单独的数据库吧?

[wgsasd311]

当然是用多表好了，一个表的话数据太多，每次查询太花时间了，表名你可以按规律取，很好做到的。

[子陌红尘]

1、几万个表不算少，但数据库可以应付得了。数据库对象包括所有的表、视图、存储过程、扩展存储过程、触发器、规则、默认值及约束。一个数据库中所有对象的总数不得超过 2,147,483,647。

2、可以放在同一个表中，根据记录归属团队的ID访问即可，如果数据量很大，可以分表，把大表分为几个表，通过访问分区视图的方式访问数据。

[hlq8210]

分多表。。
但是表的管理自己要设计好。。。
要不你的系统维护的压力会很大

[samfeng_2003]

第一，如果你的这个程序是应用为B/S的，那么你要在设计的时候考虑使用的人数的问题。如果团体不是很多，比如大概就是100多人的，你的空间只要很大，那么可以一台服务器没有问题，如果团体很多，每天数据流量大，需要存储的数据多，那么，我建议你采用多台服务器来做。
第二，对于关系数据库的设计，我们要考虑的并不是表多或者表少的问题，其实是要考虑表的合理性的问题，怎样的结果比较适合拓展和维护，尽量满足一种好的范式。比如一个成员表，我们要考虑的结果是为了以后系统的升级，成员功能的拓展，成员权限的变化，成员的变化来考虑，如果只做一个表，我想，这样的表存放大量的信息，而不能满足系统，规范，拓展的要求，那么就是潜在很大的威胁。因为，你如果大量输入数据，如果那天系统需要改进，那么这个时候你的更改是繁重的，只当就是要重新设计一次。
第三，你要好好的考虑一下用户每天的数据流量的多少，如果少的话，那么一个SQL数据库足够了。

[zjcxc]

如果各团队之间的数据共享程度要求很高,查询多数是针对和团队的所有数据.

则不应该为每个团队建立表.

否则应该为每个团队建立表.

在维护上,可以在数据库中建立一些维护这些关系的表, 通过存储过程维护这些信息

[nightlocus]

明白了,解帖

[starluck]

如果各个团队之间没有太紧的联系，分多个库倒是更好的办法

[赵为]

我的间建议也是，一个单位最好是建立一个数据库！

[nightlocus]

那要有2000个单位,不是要建立2000个数据库,对每个库的访问服务器开的可是进程了,服务器的性能不是很浪费 - -- - -