News for hackers. Stuff that matters.

A comment on Scaling Databases at Activision [pdf]. Parent comment

Re:Scaling Databases at Activision [pdf] by berkle4455 on Friday April 21, 2023 @05:36PM (#35660538)
Say you have a super basic setup:

  user = {user_id, email}
  order = {order_id, user_id}
order.user_id is a foreign key to user.user_id. That's a perfectly valid and reasonable way to organize things.

Enabling RDBMS-enforced foreign key constraints is the issue. It slows everything down dramatically.

[ Parent | on HN ]
Re:Scaling Databases at Activision [pdf] by vecter on Friday April 21, 2023 @05:44PM (#35660624)
I see, thanks. Basically just store the foreign keys yourself as columns in relevant tables and perform the joins in SQL without having the DB enforce FK integrity with every insertion/update/delete. Would it be fair to say that read speeds are unaffected by this?
[ Parent | on HN ]
Re:Scaling Databases at Activision [pdf] by berkle4455 on Friday April 21, 2023 @05:53PM (#35660729)
Yes. Quite literally the only difference is not enabling foreign key constraints. Read speeds unaffected correct.
[ Parent | on HN ]
Re:Scaling Databases at Activision [pdf] by kgeist on Saturday April 22, 2023 @04:47AM (#35664551)
>It slows everything down dramatically

How slower is it really? MySQL automically creates indexes for foreign keys so I don't think it slows down "dramatically", just an additional indexed retrieval?

Do you know of any benchmarks which show the difference?

[ Parent | on HN ]