RDBMS 数据关系负担
我们的内部系统基于 SQL Server 2008 构建，具有 40 个表 6NF 架构。大多数表 FK 到其他 3 个，关键少数多达 7 个。系统最终将支持 100 名员工与 1000 名客户一起工作，并存储 100 名或 1000 名交易记录 - 黄金时间访问应该峰值速度为每秒 1000 行。
有没有理由认为这种深度的 RDBMS 相互关系会使使用具有充足 RAM 的现代硬件构建的系统负担过重？我正在尝试评估在进入最终开发阶段（几个月后）之前我们是否需要调整我们的设计或项目方向/目标。
Our in-house system is built on SQL Server 2008 with a 40-table 6NF schema. Most of the tables FK to 3 others, a key few as many as 7. The system will ultimately support 100s of employees working with 10s of 1000s of customers and store 100s of 1000s of transactional records -- prime-time access should peak at 1000 rows per second.
Is there any reason to think that this depth of RDBMS inter-relation would overburden a system built using modern hardware with ample RAM? I'm attempting to evaluate whether we need to adjust our design or project direction/goals before we approach the final development phase (in a couple of months).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 SQl Server 术语中，您所描述的是一个小型数据库。通过正确的设计，SQL Server 可以处理 TB 级的数据。
这并不保证您当前的设计可以表现良好。有很多方法可以构建性能较差的 t-SQL，并且有很多糟糕的数据库设计选择。
如果我是你，我会将测试数据加载到你期望表大小的两倍，然后开始测试你的代码。负载测试也可能是一个好主意。在数据库性能问题投入生产之前解决它们要容易得多。容易多了！
In SQl Server terms what you describe is a smallish database. With correct design SQL Server can handle terrabytes of data.
This is not to guarantee that your current design may perform well. There are many ways to construct poorly performing t-SQL and many bad database design choices.
If I were you I would load test data to twice the size you expect the tables to have and then start testing your code. Load testing might also be a good idea. It is far easier to fix database performance problems before they go to production. Far, far easier!