Chvalov
@Chvalov

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

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

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

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

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

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

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

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

Идем дальше, скрипт VideoPro за 40$
Как вам такой вариант мультиязычности на сайте ?
ELBr5M5.png
  • Вопрос задан
  • 756 просмотров
Пригласить эксперта
Ответы на вопрос 6
profesor08
@profesor08
То, что проект взлетел, это еще не значит что внутри он идеален. Сначала делали mvp, а потом: раз работает - не трогай.
Ответ написан
@Fafhrd
Внешние ключи имеют perfomance impact при частой вставке, а при чтении от них толку никакого, любой нормальный оптимизатор прекрасно работает с обычными индексами.
Накладные расходы на хранение.
Желание сделать поддержку нескольких СУБД, тут чем меньше логики в базе, тем лучше.

А стремление все сделать по букварю и НФ приводит к печальным последствиям, особенно когда rps начинает расти нелинейно, а базка перевалила за пару сотен гигов.
Это если кратко.
Ответ написан
Комментировать
MetaAbstract
@MetaAbstract
Архитектор информационных систем и баз данных. Ful
Мотивации может быть две:
1) усложнить анализ структуры базы данных
2) упростить обновление системы, т к ссылочная целостность добавляет сложности алгортиму
Ответ написан
Комментировать
gobananas
@gobananas
finishhim.ru
Потому что внешние ключи есть в InnoDB, а раньше довольно много проектов работало на MyISAM
Ответ написан
Adamos
@Adamos
Версия.
1. Вы выкатили коммерческий код и взяли деньги за его поддержку.
2. На стороне клиента админ влез в базу через PMA и начал работать с ней методом "ногой в дверь", база в ответ заваливает его ошибками про неконсистентность ключей.
3. Вы пытаетесь решать проблемы до тех пор, пока не понимаете, что делаете за него его работу.
4. И однажды говорите "да ну их на хрен, эти ключи, не такой от них профит, чтобы иметь столько головной боли"...
Ответ написан
Комментировать
Свои 5 копеек внесу: с 70-х годов, когда разрабатывались стандарты и нормализации БД все уже раз 100500 изменилось
Агрегация и дублирование БД - это уже не просто нестандарт, а моветон.
Вспомните мощность тех ЭВМ и современных...
Кстати, и с паттернами проектирования та же ситуация , и с фреймворками - задумывалось раньше под одни цели, цели меняются и инструменты адаптируются .
Так было и будет всегда, в этом и есть развитие технологий
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы