Комментарии 6
Необходимо обращать внимание на то, какие запросы выполняются чаще всего, и оптимизировать их для повышения производительности.
Не так. Следует обратить внимание на то, какие запросы в целом (за сессию, за сутки, и т.д.) занимают больше всего времени на выполнение - и оптимизировать их. Более того, часто это не просто запросы, а целый неоптимальный набор связанных запросов, и надо оптимизировать целый набор - на стороне приложения или через написание аналогичной, но эффективной встроенной функции.
Кстати, в одном крутом и большом западном банке была большая база референсных данных (то есть, только одни запросы на чтение от множества клиентов) с почти тысячью таблиц и с миллионами записей а некоторых. И во всей этой махине не было ни одного ключа вообще! Ни primary, ни foreign. А за ней присматривала целая команда "крутых" DB-админов, которые отвечали на любые запросы/вопросы через неделю, а часто их вообще игнорировали, нотому что ну очень крутые. Документации по базе ноль, конечно же.
Есть ещё место чудесам в нашем мире! ?
:-) И даже "не так" как вы описали...
На первом этапе проектирования (если хотите получить в результате масштабирование) нужно:
- Узнать/понимать какие данные, объем и возможность "расширения" их исходного набора полей/свойств добавляются, обновляются и удаляются в БД (и в каком % соотношении).
- Узнать/понимать какие данные, в каком объеме и с какой частотой выбираются/получаются из БД
В противном случае получите "правильную" БД , но с проблемами масштабирования производительности... В которой запросы и структуры нужно будет в последствии оптимизировать. Любая оптимизация запросов в БД - следствие "недоработки" на этапе проектирования этой самой БД (ну и прикладного ПО использующего данную БД).
Некоторые моменты спорные - в угоду масштабируемости сейчас можно принести многое. В частности внешние ключи. Иногда и нормализацию.
Проектирование хорошей БД как раз обычно учёт текущих запросов и некоторое прогнозирование будущих. То что хорошо для базы с 100 rps может быть катастрофически для базы с 100k rps. И это даже не учитывая профиль нагрузки.
В итоге - правила хорошо проектирования это взвешивание плюсов и минусов каждого решения.
Статья -- рекламный спам. Целевая аудитория непонятна. Учитывая количество годного материала по теме, появлений материала можно объяснить только рекламой.
Боюсь писать статьи на Хабр. Что-то интересное мне, после освоения кажется таким простым и очевидным, что странно об этом писать. А если то, что интересно - то обычно это то, что сейчас изучаю, но кому интересны мысли недоучки, тут же профи разномастные.
А потом читаешь вот такие капитанские статьи и удивляешься. Чего боялся, пипл хавает?
Ожидал чего-то интересного, глубокого. А тут введение в БД на уровне технарского урока...
Проектирование реляционных баз данных: основные принципы