doublefint Достоинства
- Единая структура связей

Ну я бы еще добавил
- Единый ООП интерфейс с возможностью переопределения/расширения базовых методов/триггеров в потомках
- Более автоматизированное и надежное поддержание целостности. Не будет такого что на один "базовый" объект груз вдруг начнут ссылаться два разных подкласса, или при удалении объекта подкласса "базовый" останется висеть в базе. Обе проблемы решаемы, но требуют дополнительных усилий.

Так что получили три достоинтсва против трех недостатков :)

doublefint


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

kolesovКогда ИРИС ждать-то?

Ну вообще вышел уже. Пробную версию на 90 дней здесь дают https://www.intersystems.com/learn-play/

Бесплатная Community Edition в ноябре обещается.

MX-9,

С WRC можно скачать полную версию или field test - так же как Cache. Бесплатные версии, скорее всего, только в контейнерах и облаках будут.

doublefintНужно быстродействие - "no more persistent inheritance", "no more relationship", "no more OOP"

Ну тут не совсем согласен. Сила Cache - в том числе в возможности одновременного использования всех трех подходов к данным (Direct / SQL / Objects) на одной и той же базе. Так что есть вариант использовать, например, прямой доступ через глобалы для построения сложного квартального отчета, и ООП для ввода и верификации данных. Или наоборот, если большой поток входных данных - сохранять их через глобалы и использовать SQL / Deepsee для их анализа с использованием индексов.

Я согласен с тем, что категоричные заявления - это плохо. Но с другой стороны, начинающий разработчик зайдет сюда и увидит - ага, объекты это медленно. И наследование - плохо. Но с моей точки зрения это как доказывать что все что не написано на Ассемблере или на худой конец С - это медленно и отстой. А если оно еще и выполняется в виртуальной машине то вообще тушите свет. Технически они возможно правы - любой кусок приложения можно заставить выполняться быстрее если переписать его на С и ассемблере. При этом понятно, что для большинства прикладных задач это не существенно. Так же и со стандартными схемами хранения Каше. Понятно, что продвинутый программист под конкретную задачу может написать более оптимизированный код / схему хранения. Однако как вы правильно заметили

doublefintА вот тратить эти усилия или нет - зависит от конкретной ситуации.

И я считаю, что в большинстве случаев правильный ответ - "нет". Как и с ассемблерными оптимизациями.

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