[radicality]

A lot of it depends on the use case. For example, Facebook - one of the largest (if not the largest) deployments of mysql does not allow any FK constrains. There’s multiple reasons, but one of those is better predictability of db operational perf - a row delete should delete just the row and not potentially trigger N cascading deletes.

[pindab0ter]

I don't understand “a row delete should delete just the row and not potentially trigger N cascading deletes”. If you want that to not happen, then define that in the database definition. It sounds like you're saying that a core piece of functionality is somehow ‘wrong’, even though that same functionality can be used to make the desired bahviour for this exact use case explicit?

[skyde]

facebook data model is a Graph where each row store one object “comment” or one association “comment is with post id” between objects .

They made an query and indexing system on top of it to make it fast called TAO.

Without it you need to send a distinct SQL query pet parent object to get list of associated child object which would be awfuly slow.

[radicality]

Non-tao use cases of mysql at FB also cannot use FK constraints (or ‘triggers’).

[skyde]

by "no FK contraints" do you mean "no join using index" or you simply mean foreign key violation is not checked.

[goto11]

Cascading deletes is a separate from FK constraints. You can have FK constraints without cascading deletes.