Почему коммерческие web скрипты не используют внешние ключи?

Question

[Chvalov]

Ради эксперимента и общего развития хотел посмотреть как проектируют базы даных коммерческие скрипты, для этого взял около 15 различных проектов с форумов и warez ресурсов.

Но ни единый из них не используют внешних связей, при том что ключи в таблицах встречаются, также есть промежуточные таблицы, но нету внешних ключей.

Вот часть скриптов которые проверялись: XenForo 2, ClipBucket Enterprise, phpVibe, VideoPRO...

Вопрос, в чем нюанс внешних ключей, возможно есть подводные камни ? (раз коммерческие проекты ними пренебрегают)

Приколы и дебильные реализации (Мое мнение)

Взять к примеру скрипт за 5к зеленых ClipBucket, встречаются жуткие моменты, возможно я чего-то не понимаю ?

Вот отсортировал таблички и выделил слоем:
int длиной 255 символов ?
по поводу локализации таблица cb_languages поле language_code VARCHAR(8), и таблица с переводами слов cb_phrases поле lang_iso VARCHAR(5), проще было добавить поле lang_id, но прикол в другом в одном месте длина 8 символов, в другой таблице 5....

Идем дальше, скрипт VideoPro за 40$
Как вам такой вариант мультиязычности на сайте ?

Comments

[Талян]

Это реально кто-то перевод столбцами таблицы замутил???? О_О

[Chvalov]

Анатолий, да, вот полная картина отсортирована с выделенными слоями, таблица с переводом отображена не полностью !

[Chvalov]

Анатолий, и таких приколов есть множество, но меня больше интересует почему крупные и авторитетные скрипты как тот же XenForo не использует внешние ключи, подборку таких прикольных ER моделей могу собрать и опубликовать где-то на Reddit, так как тут не место для этого, а там хоть шанс есть привлечь внимание ;-)

Answer 1

[profesor08]

То, что проект взлетел, это еще не значит что внутри он идеален. Сначала делали mvp, а потом: раз работает - не трогай.

Comments

[Chvalov]

Ну если бы речь шла о двух-трёх проектах, уже 18-19 проектов поднял в целях найти интересные реализации и не единого внешнего ключа ;-(

Попадаются варианты где красиво и логично все сделано, есть ключи и промежуточные таблицы, но ни единого внешнего ключа :-(

[profesor08]

Потому, для большинства, база данных это просто набор табличек с колонками, они умеют их создавать, редактировать, удалять, менять данные, и считают что этого достаточно. Отсюда и такое количество проектов, а когда проект запущен на полную, серьезно менять архитектуру никто не хочет, ведь и так работает же.

Answer 2

[Fafhrd]

Внешние ключи имеют perfomance impact при частой вставке, а при чтении от них толку никакого, любой нормальный оптимизатор прекрасно работает с обычными индексами.
Накладные расходы на хранение.
Желание сделать поддержку нескольких СУБД, тут чем меньше логики в базе, тем лучше.

А стремление все сделать по букварю и НФ приводит к печальным последствиям, особенно когда rps начинает расти нелинейно, а базка перевалила за пару сотен гигов.
Это если кратко.

Answer 3

[Артемий]

Мотивации может быть две:
1) усложнить анализ структуры базы данных
2) упростить обновление системы, т к ссылочная целостность добавляет сложности алгортиму

Answer 4

[Дмитрий Дарт]

Потому что внешние ключи есть в InnoDB, а раньше довольно много проектов работало на MyISAM

Comments

[Chvalov]

В этом что есть, правда простительно старым проектам которые перешли с MyISAM.
Но проекты которые выпущены год-два на рынке уже со старта использовали InnoDB.

Answer 5

[Adamos]

Версия.
1. Вы выкатили коммерческий код и взяли деньги за его поддержку.
2. На стороне клиента админ влез в базу через PMA и начал работать с ней методом "ногой в дверь", база в ответ заваливает его ошибками про неконсистентность ключей.
3. Вы пытаетесь решать проблемы до тех пор, пока не понимаете, что делаете за него его работу.
4. И однажды говорите "да ну их на хрен, эти ключи, не такой от них профит, чтобы иметь столько головной боли"...

Answer 6

[Владимир Буковский]

Свои 5 копеек внесу: с 70-х годов, когда разрабатывались стандарты и нормализации БД все уже раз 100500 изменилось
Агрегация и дублирование БД - это уже не просто нестандарт, а моветон.
Вспомните мощность тех ЭВМ и современных...
Кстати, и с паттернами проектирования та же ситуация , и с фреймворками - задумывалось раньше под одни цели, цели меняются и инструменты адаптируются .
Так было и будет всегда, в этом и есть развитие технологий