Идеологи баз данных выступают резко против хранения избыточной информации в базах данных. К сожалению, в реальной жизни, соблюдение этого принципа влечёт за собой настолько сильное повышение нагрузки на систему, что приходится прибегать к идеологически-неверным решениям. К сожалению, нигде никто не пишет и не изучает, а как правильно хранить избыточные данные и какие бывают подходы. Материалов на эту тему - ноль. Для себя я пока открыл вот что: Подход первый. Избыточные данные - это полноправная часть всех даных. В этом случае за создание и чтение избыточных данных отвечает модель. При создании данных вы делаете два инсерта в две разные таблицы из одной процедуры. Это самое простое решение, но про существование избыточности часто забывается. Вы сделали два инсерта, а при изменении, забыли про существование второй таблицы и сделали только один апдейт. Подход второй. Избыточные данные живут в системе на правах кэша. В этом случае за создание и чтение избыточных данных отвечает контроллер. Модель остаётся стройной и красивой. При создании данных вы делаете один инсерт в одну таблицу. Дальше, например, раз в сутки, запускается скриптик и все созданные за этот день данные дублирует в другие таблицы. Модели остаются стройными, код гораздо легче поддерживать, гораздо проще осуществлять перенос моделей в другие проекты. Но данные обновляются не в реальном времени. Сейчас я использую комбинированный подход. Модели не знают ни про какую избыточность. Но если вызывается какая-то процедура модели, то после неё контроллер обязательно запускает другую процедуру, отвечающую за генерацию избыточных данных. Это более-менее решает проблему с созданием и обновлением данных в реальном времени, но не с чтением. Получается так, что за чтение модели почти вообще не отвечают. Как храните избыточные данные вы? По каким принципам?
Смотря какая задача. Дублирование. Обычно всё упирается в задачу и бывает что есть варианты использовать что-то кроме реляционной.
Это-то понятно. Вопрос в паттернах. Как это сделать наименее уродливо NoSQL решения я не понимаю. Хранилище типа key-value можно и в SQL сделать без проблем, гибкости от этого не прибавляется. С распределёнными системами я дела не имел, там возможно, они всё сильно облегчают, а для обычных стандартных систем NoSQL для меня никакими плюсами не обладают, только минусами. Задачи в большинстве случаев - это сортировка и фильтрация. Вам нужно получить данные из одной таблицы и отсортировать их по столбцу из другой. Или отфильтровать данные по столбцам из разных таблиц. Больше я ни с чем не сталкивался, где нужно было что-то оптимизировать.
Есть теорема CAP и задача + тесты, прогоняем пару алгоритмов и выясняем что нам нужно. Может у тебя задача делать быстро и пофиг на железо. Есть специальные движки sphinxsearch, elasticsearch (apache lucena) их обычно и используют.
Идеологи баз данных свою идеологию рожали в шестидесятые наверное. Сейчас без денормализации нельзя даже пёрнуть.
я говорю именно о нагрузке. Конечно можно делать нормализованную бд. Для этого есть все возможности и мощность движков и языка запросов. Но оборачивается это нагрузкой на проц, которую легко снять денормализацией. При чем это не обязательно некая критичная денормализация. Например на форуме топик может хранить номер, дату и автора последнего сообщения. Никто не умрёт, а отрисовка списка тем будет быстрее на голову.