mad_nazgul
У-у-у вы даже ООП не знаете.
Классический пример с геометрическими фигурами.
Есть абстрактный класс "Фигура" у которой есть метод "нарисовать".
Есть потомки "квадрат", "круг", "треугольник".
У которых переопределен метод "нарисовать".
Данные разные, классы разные, используются одинаково!


Умник, попробуй эти данные после рисования куда-нибудь СОХРАНИТЬ, а потом проиндексировать и ПОИСКАТЬ фигуры, входящие в заданую область.

mad_nazgulНе знаю, просто всегда когда перед ORM ставиться задача чуть сложнее прочитать несколько строк из таблицы.
Тут же возникают ХП.


Ну и что же в этом прохого, в чём проблема ?
Объекты Hiber (или кто ещё) легко может читать и из процедур,
и можно вообще не использовать Hiber именно в этом отдельном месте.


mad_nazgul1) ХП не относиться к РМД. Это процедурное расширение РМД.


Напомню, что РМД расшифровывается как "реляционная модель ДАННЫХ". Код не обязан подчиняться модели ДАННЫХ.
Всё, на твоём уровне развития я с тобой общаться не хочу. Неинтересно.

авторORM - это, конечно, хорошо, и при правильном использовании несет много пользы, но правильно использовать его очень тяжело, а при неправильном он генерит очень неоптимальные запросы.


Правильно его использовать ОЧЕНЬ ЛЕГКО. Ну, ладно, просто легко.
С GRAILS например -- очень легко. Просто ключ тут в слове "правильно".
А это значит -- не забивать гвоздь отвёрткой, а шуруп не закручивать молотком.


авторКто-нибудь знает книжку по данному вопросу? или хотя бы ключевые слова?

Я не понял, о чём это. если хочешь -- уточни, может скажу книгу.

scfКлассический подход - (местами) нормализованное хранилище, со связами один-ко-многим и многие-ко-многим через таблицы, местами денормализованное для повышения быстродействия плюс тщательно затюненные индексы для того, чтобы все нужные запросы работали быстро.


Забудь про выделенное, это уже давно неработающий бред. Давно неправда.
Денормализация никогда не приводит к повышению быстродействия, потому что она приводит к росту физического объёма данных, а оно ведёт к коллосальному падению производительности. Сейчас решения в VLDB строятся наоборот на гипернормализации и сжатии на физичесом уровне хранения данных.

scfАльтернатива? Одна таблица с тремя полями: id, номер полиса, clob с json-ом.

Плюсы:
...

Проблемы и пути их решения:


На самом деле проблем только одна -- это не база данных, не хранилище данных, а склад данных. Данные в таком складе невозможно обрабатывать средствами СУБД, внутри БД. Почти все описанные тобой проблемы -- это следствие этого.

Фактически ты вообще предлагаешь закинуть всё в некое хранилище, и не решать ни одну из проблем из области использования этих данных -- поиск и сортировки как делать -- ты не знаешь, аналитику предлагаешь делать во внешней БД (OLAP), в которую ты даже не знаешь, как эти данные выгружать.

А какую ж из задач по созданию системы для хранения и обработки этих данных ты тогда решил ?
Простую вставку данных? Но она и на ORM + RDBMS решается неплохо.

Я тебе сообщу о ещё одной проблеме, которую ты не видишь -- это проблема консистентности (т.е. целостности данных).
Кто будет проверять твой JSON перед вставкой в БД ? БД этого не сделает. А в JSON формат данных свободный, можно и добавить лишний атрибут, и не добавить обязательный, а обнаружишь ты это только на уровне приложения.

scfЯ пришел к выводу, что классический/школьный подход к разработке БД а-ля "нормализуйте все, нафигачьте справочников, пишите сложные запросы


В общем, как резюме к топику.
У тебя в голове -- каша. Нет порядка, нет чёткого понимания, что где и зачем.
Не обижайся -- это нормально, это на каком-то этапе у всех так.

Тебе сейчас надо не делать какие-то выводы, а просто поработать так, как все, в стандартных технологиях.
Поднабраться опыта, понять, проанализировать, потом уже делать выводы.

Infernal V. RavenMasterZivДенормализация никогда не приводит к повышению быстродействия, потому что она приводит к росту физического объёма данных, а оно ведёт к коллосальному падению производительности. Сейчас решения в VLDB строятся наоборот на гипернормализации и сжатии на физичесом уровне хранения данных.

wikiДенормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных.Не?

А что неправильно ?

Написано, что ЦЕЛЬ денормализации -- УСКОРЕНИЕ. Это то, для чего её делают. Но это не значит, что если сделали, то достигли цели.

Кот МатроскинMasterZivДенормализация никогда не приводит к повышению быстродействия, потому что она приводит к росту физического объёма данных,

Это неправда - нормализованные данные запросто могут занимать больший объем, нежели ненормализованные.
Задача нормализации вообще не в том, чтобы экономить место - это всего лишь необязательный сопутствующий бонус.

Ну-ка расскажи подробнее...
Пока -- смешно.
Ну да, в каких-то самых простейших случаях так может быть, типа табличка в две строчки, и 20 справочников.
Но стоит ли об этом исключительном случае говорить ?