千行的最佳数据库设计是什么

bal*_*dre 5 sql-server database-design database-normalization

我即将启动一个数据库设计,它将简单地管理公司下的用户.

  • 每家公司都有一个可以管理用户的管理区域
  • 每家公司将拥有约25.000名用户
  • 客户认为有大约50家公司开始

我的主要问题是

我应该根据公司创建表格吗?喜欢

users_company_0001 users_company_0002 users_company_0003 ...

因为每个公司永远不会使用"其他"用户,并且不需要在所有user_company中对不同的表进行求和/计数(一个简单的方法JOIN可以做到这一点,虽然它更昂贵(时间)它将起到主要图片的作用,这将永远不会被需要.

或者我应该创建一个users表(50 x 25000)1 250 000个用户(并且还在增长).

我正在考虑第一个选项,但是,我不确定如何在这样的布局上使用Entity Framework ...我可能需要回到90年代并手动生成我的数据逻辑层.

它是对包含公司标识的商店程序的简单调用

你会建议什么?

系统应用程序将是ASP.NET(可能是MVC,我仍然试图解决这个问题,因为我所有的知识都是关于webforms的,虽然我看到Scott Hanselman MVC视频 - 接缝很容易 - 但我知道它不会那么容易问题将来临,我将花费更多时间来修复它们,以及Microsoft SQL.

Joe*_*lli 9

尽管您已将此描述为1-many关系,但我仍然将数据库设计为多对多,以防止未来需求的变化.就像是:

替代文字


mat*_*mc3 7

我已经使用了一个数TB的SQL Server数据库,并且在我的职业生涯中拥有数百万个表的经验,数百万行,我可以完全保证SQL Server可以处理你的companyusers没有分区的表.它总是存在于您需要它的时候,但您的担心不应该是关于您的表 - 选择最符合您需求的模式.如果你想做一些事情来优化性能,你的瓶颈肯定会是你的磁盘.不要购买大而慢的磁盘.获取一堆小的高RPM磁盘,并尽可能地将数据传播到它们之间,并且不要与日志和数据共享磁盘.使用数据库,您几乎总能通过良好的硬件,良好的磁盘子系统和正确的索引来实现性能.不要为了预期性能而妥协并使您的架构复杂化 - 您会后悔的.我已经看到了很大的数据库,这些东西是必要的,但你的不是它.