数据库关系与软件解决方案保持一致性（性能）
从我的角度来看，数据库始终是瓶颈。因为我可以将CPU功率调整到任何需要的值。即使使用集群或复制，数据库资源也是有限的。我在这里可能是错的，但这些是我迄今为止使用云软件的经验。
所以我认为保持数据库的关系会节省数据库资源，不是吗？
例如，如果您有一个 users 表和一个 user_friends 表。 user_friends 中的外键是 users 表的主键。因此，如果我在用户表中有类似 ON DELETE 的关系 -> DELETE FROM user_friends...数据库将神奇地保持一致性并运行所有需要的查询。如果我的软件运行两个简单的查询 DELETE FROM users WHERE user_id... 和 DELETE FROM user_friends WHEREfriend_id... ，不是更快吗？
当然，下降可能会出现不一致，但这根本不会减少数据库负载吗？
From my point of view the database is always the bottleneck. Since i can scale the cpu power to any needed value. The db ressources are limited even with clustering or replication. I might be wrong here but these are my expierences so far with cloud software.
So I think that to keep relations off the db will save db ressources won't it ?
For instance if you have a users table and a user_friends table. The foreign key in user_friends is the primary key of the users table. So if I have relations like ON DELETE in the users table -> DELETE FROM user_friends... the database will to the magic to keep consistancy and run all the needed querys. Isn't it faster if my software will run two simple queries DELETE FROM users WHERE user_id... and DELETE FROM user_friends WHERE friend_id...
The downfall will be possible inconsistancy of course but doesn't this reduce the DB load at all ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在我看来，您应该使用独立的对象（行）而不是关系，这样您就不需要再使用任何复杂的查询。除此之外，它将使缓存查询变得更加容易（服务器端和数据库端）。
为了防止不一致，您应该使用：
所以，基本上，它可能更难编码，但它会给你一个更好的数据库设计，具有令人难以置信的性能，并且非常可扩展。
顺便说一句。如果您确实考虑不使用关系，我建议您使用 no-SQL-db。 SQL 数据库很难扩展（与非 SQL 数据库相比），并且当您不使用关系时（同样与非 SQL 数据库相比）会导致大量开销。
In my opinion, you should use independent objects (rows) rather than relations so you don't need to use any complex queries anymore. Besides that, it'll make it a lot easier to cache your queries (both server-side as db-side).
To prevent inconsistency, you should use:
So, basically, it's probably harder to code, but it'll get you a better db-design that has an incredible performance and that's very scalable.
Btw. if you do consider not to use relations, I'ld recommend you to use a no-SQL-db. SQL-databases are pretty hard to scale (compared to no-SQL-databases) and cause a significant overhead when you don't use relations (also, compared to no-SQL-databases).