On 25.08.2014 21:25, scf wrote:

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

Ты пришёл к неверному выводу.


> - В крупных БД с десятками миллионов записей явные FK не используются, а
> кол-во констрейнтов сильно ограничено, ибо индексы.

Используются. Вторая часть утверждения -- пока просто неразличимый бред.


> - Датабазные джойны дороги. По моим старым замерам в mssql, запрос без
> джойнов работает примерно раза в 2 быстрее, чем запрос с одним джойном
> по ПК.

Это тоже бред. JOIN по индексу -- очень дешёвая операция.
А сравнивать "запрос без джойнов" с "запросом с одним джойном по ПК" --
это вообще верх непрофессионализма -- запросы разные бывают, к тому же я
полагаю, что твои способности замерять производительность запросов
достаточно примитивны.


> Сначала о справочниках. Зачем их джойнить при загрузке объекта?
> Приличные приложения справочники кешируют у себя и джойнят сами, руками
> или тем же Хибернейтом.

СУБД это сделает в 100 раз быстрее и эффективнее, чем все остальные.

Или еще лучше - почему бы не встроить данные из
> справочника в сам объект, раз уж почти всегда требуется, чтобы сущности
> после создания не менялись при изменениях справочников?

Денормализация. Ересь.


> Бизнес-объекты. Обычно представляют из себя в базе мессиво мелких
> табличек, призванных отобразить разнообразные вложенные коллекции. Это
> мессиво сложно использовать и непрактично извлекать - см. цену джойнов.
> Почему бы тогда не зафигачивать данные в одну таблицу json-ом или
> аналогичным форматом? Ответ на вопрос "а как тогда селекты делать" чуть
> ниже, а пока назову только одну причину - "без приложения эти данные
> сложно извлечь, т.к. они не описаны в схеме".

У тебя каша в голове. Бизнес-объект, который ты имеешь в виду, никогда
почти не нужно иметь вне БД целиком, в полном виде. А когда закачиваешь
только те аспекты объекта, что нужны, таких проблем не будет.

> Что касается селектов или какого-то поиска. Селекты, где критично
> получить именно актуальные данные в транзакции - почти всегда примитивны
> и просты. Все остальное отлично покрывается внешними индексирующими
> приложениями вроде Apache Solr или Sphinx. В своей сфере они работают
> намного эффективнее СУБД.

Нет, это неправда. Это системы полнотектового индексирования.
Если они встроены в СУБД (а они встроены во многие СУБД), то они так же
эффективны, как и внешние индексаторы.


> Что получается в итоге?

В итоге получается фарш из каши из твоего головного мозга, я понял.
:-)


Таблицы состоят из небольшого набора полей плюс
> клоб с Json-ом. Справочники есть, но большинство справочников
> используется только для создания новых объектов (данные из справочника
> встраиваются в сам объект). Простые и важные селекты идут по тем
> немногоим полям, которые остались в таблице. Сложный поиск делается
> специализированным софтом, данные в которое импортируются в рантайме
> приложением, которое висит на этой базе (в тяжелый случаях - джобой).
> Аналитика и кубы - на отдельной базе, с отдельным олап-кубом или тупо
> импорт в qlikview или подобную штуку.


> И, собственно, что хотелось бы услышать. Чем такая схема плоха?

Тем, что она будет работать только для определённого рода приложений,
которые ты, по видимому, только и разрабатывал. Например, все внешние
индексаторы типа Apache Solr или Sphinx работают с данными off-line,
т.е. в них хранится некий слепок БД из прошлого, отдалённого от
настоящего настолько, насколько просто обновлять эту БД. Соотв., чем
больше БД, тем сложнее её обновлять.


> большинство справочников используется только для создания новых
> объектов (данные из справочника встраиваются в сам объект).

Это денормализация, опастность взрывного увеличения объёма данных.


> Для приложений?

Уже написал.

> Для быстродействия или DBA?

Быстродействие к этому индифирентно. Т.е. быстродействию пофиг.


> Для архитектуры системы в целом?

Архитектура системы должна подбираться под задачу, а не наоборот.
Твоя архитектура, ещё раз, не универсальна, под любую задачу она не
подойдёт.

> Для управления данными в этой базе в долгосрочной перспективе?

Для управления данными нужны хорошие системы хранения данных.
Реляционные таблицы -- это хорошие системы хранения данных.
JSON в блобе -- это неизвестно что, как его обрабатывать с помощью СУБД
-- не понятно. Хорошо, если в СУБД есть поддержка JSON-а, а если нет?
Posted via ActualForum NNTP Server 1.5

On 26.08.2014 08:32, mad_nazgul wrote:

> В ООП все так как вы говорите.
> А РМД немного другое.
> Нельзя "как есть" сохранить объекты в РБД.

Да можно.

> Т.к. в РМД структура данных не должна меняться часто (в идеале вообще
> неизменна)
> В отличии от ООП. Здесь "изменчивость" это основная "фишка".

Нет, основная фишка в ООП -- не изменчивость, а инкапсуляция и полиморфизм.


> На стыке данных технологий происходит весь холивар.
> РБД "заточены" на хранение данных ACID наше все.
> ООП наоборот на "работу" с данными их изменение.
> Там где важно накопление точных данных, там всегда РМД (в основном финансы)
> Там где это не важно, а важно быстро изменить структуру данных, там
> обычно разные NoSQL решения.

Это ты говоришь про Schemaless. Это не одно и то же с NoSQL. Одно не
означает другое, и наоборот.

РБД есть и такие, которые заточены не на ACID, а на хранилища данных.


> ООП применяется и там, и там, но при использовании РБД с РМД начинается
> "конфликт интересов".

Нет такого конфликта, он выдуман.

> Разработчики ООП "плюются на" РБД, что там нельзя изменить структуру как
> им удобно, а разработчики под РБД "фигеют", что программисты ООП не
> хотят/не могут сделать нормализацию данных.

Это надумано. Нет такой проблемы. Если хочешь, менять структуру БД даже
и проще, чем структуру объектов -- в БД это просто изменение структуры,
в ООП надо ещё и переписать все программы, которые используют эту
структуру. Если в БД есть ещё и код, то та же проблема будет и в БД --
надо переписывать и триггера, и процедуры.
Posted via ActualForum NNTP Server 1.5

On 26.08.2014 16:10, mad_nazgul wrote:

> Это приведет к проблеме о которой вы писали.
> Поэтому нельзя ;-)

На сколько я помню, я не говорил ни о каких проблемах.

> Т.к. данные в РМД и данные в виде объектов это по большому счету разные
> вещи.

Данные -- это данные. Ещё раз, т.н. object-relational gap -- выдумка.
Она вызвана грубо говоря тем, что в РМД нет массивов. Но всё это
решается. См. решения в Hibernate etc.


> А для чего нужны "инкапсуляция" и "полиморфизм"?!

Если ты пишешь объекты куда угодно в БД (любую), то тебе надо забыть о
инкапсуляции, это -- раз. Поэтому обеспечить просто изменчивость
объектов в этой БД невозможно ( сложно так же, как и в РБД ).

> Чтобы обеспечить "изменчивость".

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

> Мы скрываем как "внутри" устроен объект, чтобы его можно было менять как
> нам нужно.

Это очень наивное представление о проблеме.


> MasterZiv
> РБД есть и такие, которые заточены не на ACID, а на хранилища данных.
>
> На сколько я помню они либо вымерли, либо их занимают ну очень
> специфичную нишу.
> Сейчас балом правит SQL ;-)


Нет, скорее наоборот, их сейчас очень много.

> MasterZiv
> Нет такого конфликта, он выдуман.

> Но он есть.
> И я его наблюдаю не на одном проекте.
> Как только начинается использоваться ORM, так сразу он и возникает.

Обычно я такие слова слышу от людей, которые просто не умеют работать ни
с объектами, ни с РБД, ни с ОРМ.

> Т.к. со временем любое обращение к БД ч/з ORM обрастает кучей ХП
> (хранимых процедур).

И что в этом плохого, в ?

Posted via ActualForum NNTP Server 1.5

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


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