Давайте возьмем избитый до смерти пример движка блога.
У вас есть блог, в блоге есть сообщения, в сообщениях есть теги для организационных целей.После того, как мы решили, что проблема с тегами не является тривиальной в среде СУБД, мы отправляемся в Google для получения рекомендаций и в качестве первого попадания находим следующее краткое изложение решений: проектирует и связанные тесты .Тем не менее, все они идут за счет производительности или сложности.Похоже, что NoSQL-подобный подход, позволяющий хранить список тегов в столбце (в NoSQL мы можем хранить документы в документах), решит проблему хорошо.Почему бы не SQLServer / Qracle / MySQL / Postgres / и т. Д.тогда?
Сначала я подумал, что это может быть из-за разного размера.Но любая СУБД, на которую стоит обратить внимание, допускает некоторую форму varchar и текста (существенного размера).Таким образом, размер столбца (и тот факт, что один и тот же столбец в разных строках будет иметь разный размер, не проблема).Таким образом, вместо хранения большого количества текста, давайте сохраним список элементов одного типа (массив в большинстве языков) в столбце.Позвольте нам индексировать его для эффективного точного поиска совпадений.И, по крайней мере, для всех случаев использования, в которых я нуждаюсь в NoSQL DB, необходимость исчезнет как необходимость (я знаю, что многие люди недовольны масштабируемостью, но я не знаю / не беспокоюсь об этом, у меня нет масштабируемостивопрос, у меня есть ночные кошмары).Мы получаем упрощенный дизайн нашей схемы (такой же простой и понятный, как документ в документе NoSQL) и отличную производительность благодаря эффективной индексации.Еще страннее, что в БД с открытым исходным кодом (например, Postgres) нет какого-то патча для этой функции.В наши дни разработчики, имеющие мотивацию в этой области, похоже, в восторге от создания новых БД с нуля.
Я упускаю какие-то ошеломляющие технические препятствия или вышеупомянутые поставщики СУБД просто ленивы или ушли в прошлое?