Why don't commercial web scripts use foreign keys?

Question

MySQL

For the sake of experiment and general development, I wanted to see how commercial scripts design databases, for this I took about 15 different projects from forums and warez resources.
But none of them use external relations, despite the fact that the keys in the tables occur, there are also intermediate tables, but there are no foreign keys.
Here are some of the scripts that were checked: XenForo 2 , ClipBucket Enterprise , phpVibe , VideoPRO ... The
question is, what is the nuance of foreign keys, maybe there are pitfalls? (since commercial projects neglect them)

Jokes and moronic realizations (My opinion)

Взять к примеру скрипт за 5к зеленых ClipBucket, встречаются жуткие моменты, возможно я чего-то не понимаю ?
Вот отсортировал таблички и выделил слоем:
int длиной 255 символов ?
по поводу локализации таблица cb_languages поле language_code VARCHAR(8), и таблица с переводами слов cb_phrases поле lang_iso VARCHAR(5), проще было добавить поле lang_id, но прикол в другом в одном месте длина 8 символов, в другой таблице 5....
Идем дальше, скрипт VideoPro за 40$
Как вам такой вариант мультиязычности на сайте ?

Answer 1

Foreign keys have a perfomance impact with frequent insertion, and there is no sense in reading from them, any normal optimizer works fine with regular indexes.
Storage overhead.
The desire to make support for several DBMS, here the less logic in the database, the better.
And the desire to do everything according to the primer and NF leads to sad consequences, especially when rps starts to grow non-linearly, and the bazka has exceeded a couple of hundred gigs.
This is in short.

Answer 2

There can be two motivations:
1) complicate the analysis of the database structure
2) simplify the system update, because referential integrity adds complexity to the algorithm

Answer 3

Because there are foreign keys in InnoDB, and before that quite a lot of projects worked on MyISAM

Answer 4

Version.
1. You rolled out a commercial code and took money for its support.
2. On the client side, the admin got into the database through PMA and started working with it using the "kick in the door" method, the database in response floods him with errors about the inconsistency of keys.
3. You try to solve problems until you realize that you are doing his job for him.
4. And once you say "fuck them, these keys are not such a profit from them to have so many headaches"...

Answer 5

I’ll add my 5 kopecks: since the 70s, when the standards and normalization of the database were developed, everything has already changed 100,500 times
Aggregation and duplication of the database is no longer just a non-standard, but bad manners.
Remember the power of those computers and modern ones ...
By the way, the situation is the same with design patterns, and with frameworks - it was conceived earlier for the same goals, goals change and tools adapt.
It has always been and always will be, this is the development of technology