Question

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 ?

Answer 1

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:

• transactions, so all ‘related’ data-objects are updated.
• sharding, so you won’t need to scale your db vertically. Horizontally is a lot easier (in most cases).
• replication, so when a server goes down, your app doesn’t get inconsistent.

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).