现实应用程序中每个功能有多少个连接？
我经常创建的查询有 7-8 个联接来检索数据。这些连接在真实的数据库应用程序中正常吗？还是我的数据库设计很差？我很好奇，因为如果每个请求数据库都必须做这么多工作，那么如果有几千个客户端连接它不会死吗？
The queries that i create frequently have 7-8 joins to retrieve data. Are these many joins normal in a real database application or is my database design poor? I am curious because if on each request database has to do so much work, then won't it die if few thousands of client connect?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在我看来，在某些情况下这是不可避免的，关键是为您正在执行的查询拥有正确的索引。使用 ORM 中的深层对象图，或者可能具有连接子类的对象图，很容易完成您所说的 7-8 个连接。我很想听听其他人对此的看法:)
In my opinion it's inevitable in some cases, the key is to have the correct indexes for the queries you're doing. With a deep object graph in ORM, or perhaps one with joined subclasses, it'd be easy to go over the 7-8 joins you talk of. I'm keen to hear what everyone else has to say about it :)
如果没有应用程序逻辑细节，就不可能在这方面得出结论。
如果您的应用程序逻辑导致您不可避免地进行连接以保持完整性，那么这不是问题，您的数据库平台必须处理它。
Its not possible to draw a Conclusion in this regard without the Application Logic Details.
If your Application Logic leads you to unavoidable joins to maintain the integrity Its not a Problem, and Your Database Platform must handle it.
这是很多连接。如果没有看到你的模式，很难说，但我见过人们疯狂地使模式变得过于复杂的情况。我记得我开发的一个应用程序中，系统中的每个地址和电话号码都被视为一个实体，并且查询经常涉及十多个表的联接。在创建模式时，您应该小心区分您关心的单独跟踪的事物和其他所有事物，否则最终可能会带来不必要的复杂性。
That is a lot of joins. It's hard to say without seeing your schema, but I have seen cases where people have gone nuts making a schema overcomplicated. I remember one application I worked on where every address and phone number in the system was treated as an entity, and queries frequently involved joins of over a dozen tables. You should be careful when making a schema to distinguish between those things you care about individually tracking and everything else, otherwise you can end up with needless complexity.