5

我即将开始一个数据库设计，它将简单地管理公司下的用户。

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

我的主要问题是

我应该根据公司创建表吗？像

users_company_0001 users_company_0002 users_company_0003...

因为每家公司都不会使用“其他”用户，并且不需要对所有 user_company 中的不同表进行求和/计数（一个简单的方法JOIN就可以了，尽管它更昂贵（时间）它将作为主要图片工作，这永远不会被需要。

或者我应该创建一个users表来拥有 (50 x 25000) 1 250 000 个用户（并且还在增长）。

不过，我正在考虑第一个选项，但我不确定如何在这种布局上使用实体框架......我可能需要回到 90 年代并手动生成我的数据逻辑层。

是否会是对包含公司 ID 的存储过程的简单调用

你会建议什么？

系统应用程序将是ASP.NET（可能是 MVC，我仍在尝试解决这个问题，因为我所有的知识都在网络表单上，虽然我看过 Scott Hanselman MVC 视频 - 接缝很容易 - 但我知道它不会那么容易问题会来的，我会花更多时间来解决它们），以及Microsoft SQL。

4

4 回答 4

9

即使您将其描述为一对多关系，我仍然会将数据库设计为多对多，以防止未来的需求变化。就像是：

替代文字

于 2010-09-28T21:16:20.060 回答
7

使用过数 TB 的 SQL Server 数据库，并在我的职业生涯中处理过数百个数百万行的表，我可以完全保证 SQL Server 可以处理您的company和users没有分区的表。当您需要它时，它总是在那里，但您不应该担心您的表 - 选择满足您需求的最简单的模式。如果你想做一些事情来优化性能，你的瓶颈几乎肯定是你的磁盘。不要购买大而慢的磁盘。给自己准备一堆小的、高 RPM 磁盘，并尽可能地将数据分散在它们之间，并且不要与日志和数据共享磁盘。使用数据库，通过良好的硬件、良好的磁盘子系统和适当的索引来实现性能几乎总是更好。不要为了预测性能而妥协和过度复杂化你的模式——你会后悔的。我见过非常大的数据库，这种东西是必要的，但你的不是。

于 2010-09-29T01:31:58.763 回答
3

回复：我应该根据公司创建表吗？ 是的

像

users_company_0001 users_company_0002 users_company_0003

不，像

companyID  companyName, contactID

或者我应该只创建一个用户表来拥有 (50 x 25000) 1 250 000 个用户（并且还在增长） 是的

于 2010-09-28T20:59:27.843 回答
1

我认为您应该为公司和用户创建单独的表。然后是连接两者的第三个表：CompanyAdmin。就像是：

  • 公司( Company_Id , Company_name, ...)
  • 用户( User_Id , User_name, ...)
  • CompanyAdmin ( Company_id , User_id)

通过这种方式，您可以添加用户和/或公司，而不会影响您需要管理的表格数量。当新数据（公司）添加到系统时，您需要修改数据库（即添加表）通常是一个糟糕的设计。

通过适当的索引，包含几百万行的数据库中的连接成本应该不是问题。

最后，如果您需要更改或记录有关公司、用户或他们之间关系的其他信息，此设置对您的应用程序的影响应该最小。

于 2010-09-28T21:24:21.863 回答