alatalo, возможно это поможет

alatalodoublefint,

чуть в сторону:

>Если не закрывать открытый объект ( kill, не %Close()! ), то да - рано или поздно Cache "встанет".
это почему так? Разве каше не должен закрыть объект после того, как умрет последняя ссылка на него?
Эм.. Это сильно в сторону и не ко мне

alatalo, если пройти по цепочке наследования вверх от %Persistent до %Library.SystemBase, то в документации ( Cache 2017.2 ) к его методу %Close() [Final, Internal] можно прочитать:
"This method is deprecated because we now reference count objects automatically so there is no need to call this method. It is a no-op and just returns success %Status code."
Похоже, приведенная вами цитата, начиная с какой то версии, утратила актуальность.

kolesovНаследование хранимых - часть хорошей архитектуры... если Каше, конечно ;)
"Favor object composition over class inheritance” the Gang of Four
"Subclasses are dependent on the implementation and entire hierarchy of the parent class: the tightest form of coupling available in OO design "

kolesov было бы наследование таблиц в MySQL... Есть в PostgreSQL

kolesov ... И это только один пример ... Именно. Т.е. частный случай. Как только показалось, что нашли универсальное решение для всех возможных сценариев ( "наследование наше всё" ) - готовьтесь. А развешивать ярлыки на основании своего частного случая ...
kolesov ... Задумываться не обязательно ... kolesov ... не нужно особо задумываться ... Классический kolesov :)
kolesovОт груза наследовались контейнеры, насыпные-навалочные, автомобили , нефтепродукты и проч. А потом прилетает постановка сделать приложение, работающее только, и только, например, с автомобилями.

kolesov ... Вы ЧТО показали? ... Надеюсь, что предупредил - решение имеет свои существенные недостатки. Думать надо всегда. Смешали всё в одну кучу ( хорошая архитектура, ага :) - готовьтесь разгребать. Кстати, чем можете помочь автору темы? :)
Интересный прием использования наследования можно посмотреть у самой ISC, когда базовый класс содержит параметры, по которым генерируется код наследников. Примеров хранимого наследования, навскидку, не припомню - если кто знает, подскажите.
kolesov сыплете чужими цитатами Ну, имея опыт общения с вами, вынужден. Для вас ведь никто не является авторитетом, не так ли? :) Если создатели ООП говорят быть осторожнее с наследованием, к кому же прислушаться? :)
kolesov и своей демагогией Ну что вы, в этом вы признанный лидер :) "Концентрация на частности", "ad hominem" - перечитайте свои сообщения в этой теме, можно только учиться :)

kolesov ... просто фигура речи такая получилась... Ой, я вас умоляю, это же ваш фирменный стиль общения - kolesov™ Не пройдет и двух минут... :)
kolesov ... и предлагаю различать ... Еще раз предлагаю вернуться к теме, автор которой, похоже, воспользовался "хорошим решением". В соседней теме он уже предлагает ISC переделать хранение как раз под этот случай. Так что же ему теперь делать? Расскажите, "многим пригодилось" - рано или поздно, многим тоже понадобится как это из этого выпутываться.

kolesov где не стоит тратить время ;) Вы это уже обещали :) Хм, чуть больше двух минут :)
kolesov работает, наверное, назло злопыхателям!? :)
Еще раз, пожалуйста, помогите автору темы. Итак, смешали контейнеры, нефть, автомобили и пр. Работает десятилетиями - данных много. Как теперь работать только с автомобилями. Конкретный вопрос - ваши советы. Очень вероятно, что мы просто не знаем, что известно вам.

logist в коде от ISC хранимых классов вообще не очень много. Но и не мало - см. таблицу Subclasses. Ensemble - по сути, большой пример, написанный ISC, на ее же технологиях.

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

kolesov Переформулирую в виде максимы Переформулируйте в виде простых списков - есть решение, есть достоинства, есть недостатки
kolesov некие данные должны лежать в одной глобали Это просто не наш уровень - классы наше всё. Сформулируйте предпосылки, признаки, условия, при которых стоит использовать хранимое наследование.
alatalo ... без дополнительных индексов по типу ... kolesovНу Extent же индекс!

kolesov, согласен, автор хочет странного.

Но и планировать архитектуру из, даже не требования, а просто из идеи "все должно лежать в одной глобали" ( откуда такой посыл? почему? какого? ) - не менее странно.
Начнём формулировать?

Наследование хранимых классов

Достоинства:
- Единый интерфейс для наследников
- Удобная выборка из всех наследников

Недостатки:
- Потенциальная возможность блокировки всей глобали при работе ( CRUD ) с экземплярами определенного наследника
- Необходимость объявлять Extent индекс для выборки из конкретного наследника ( похоже, для автора это проблема )

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

kolesov Я не говорил, что все в одной глобали должно... но иногда - да.kolesov ... данные должны лежать в одной глобали - необходимо отдаться судьбе и их туда таки сложить! Что именно я смешал? Общение через форум имеет свои особенности, возможно я что-то не уловил.
kolesovИз достоинств еще:
- Общее поведение, часто реализованное ОДИН раз Мы же говорим про наследование хранимых классов? Поведение появляется тогда, когда данные считаны в память с диска, так? Т.е. предпологал, что речь пойдет про свойства, индексы, связи kolesov - Единая структура связей ... Виноват, пропустил. Какой именно вид связей вы используете - relationship, foreignkey, ссылочные свойства? kolesov - Индивидуальные наборы данных, вместо "общей" таблицы на 800 столбцов ... У нас первым пунктом достоинств - простая выборка всех наследников. Приведёте пример общих полей для контейнеров, нефти, автомобилей кроме id, name? Не могу согласиться с такой формулировкой - у отдельной таблицы вполне себе индивидуальный интерфейсkolesov Про недостатки - второй смешной Кто знает, может автор забыл, и теперь у него сотни-тысячи наследников базового в супернагруженной системе, может места не хватает на дополнительные индексы, может планы запросов как-то поплывут в жизненно-важной бизнес-логике, может еще что-нибудь :) kolesov а по КРУД у меня ... У меня ... мои ... НИ РАЗУ за 20 лет. Принимается. 20 лет огромный опыт. Охватывает ли он все возможные сценарии? Хотелось бы сосредоточится на более определенных вещах, в недостижимом идеале ( servit стал реже сюда заглядывать :) со ссылками на документацию, тесты, примеры кода.

И вот это:
kolesov не нужно особо задумываться при модификациях или изменениях бизнес-требований Блок А.Н. Нужно будет намного аккуратнее продумывать индексы и запросы ...

Достоинства:
- Единый интерфейс для наследников
- Удобная выборка из всех наследников
- Единая структура и контроль связей

Недостатки:
- Одна глобаль для хранения всех экземпляров-наследников - возможность блокировки всей глобали
- Extent индекс для выборки из конкретного наследника

kolesov, если присмотреться к списку достоинств, то действительно стоящим выглядит только единая структура - ( Документ <-> Строка -> Груз ). Общий список и единый интерфейс ( список полей ) можно получить и другими способами.
В недостатки можно добавить overhead на ООП - в структуре единой глобали использются ключи с именем класса ( для индивидуальных наборов данных), для каждого экземпляра сохраняется вся цепочка наследования.

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

Недостатки:
- Одна глобаль для хранения всех экземпляров-наследников - возможность блокировки всей глобали
- Extent индекс для выборки из конкретного наследника
- Overhead на ООП

Насколько я понял, в вашем приложении наследование используется для всех трех сущностей предметной области - Документы, Строки, Грузы?

kolesov Единая структура связей, когда новый член "семьи" уже знает, кто тетка, и за что ему влетит от бати . Т.е. речь об ограничениях целостности, т.е. реализация бизнес-логики. В базовый класс никогда-никода не вносили изменения? Рано или поздно - "Subclasses are dependent on the implementation and entire hierarchy of the parent class: the tightest form of coupling available in OO design".

Наследование хранимых классов :

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

Недостатки
- "Subclasses are dependent on the implementation and entire hierarchy of the parent class: the tightest form of coupling available in OO design" ( см. п.1. Достоинств )
- Overhead на ООП ( Extent индекс, хранение списка наследования для каждого экземпляра, доп. ключи )
- Одна глобаль для хранения всех экземпляров-наследников - возможность блокировки всей глобали

kolesov Блокировки следует ожидать не столько исходя из структуры системы, а скорее из реалий бизнеса .... когда сотня операторов создает и правит одни и те же документы 24х7 ... проблема закрывается ... отдельным частным механизмом разруливания конфликтов доступа и блокировок. Да что вы говорите! Готовы переформулировать "максиму" ? :)

logist ... обсуждаем выбор между наследованием и композицией, т.е. практически
vs
...Предлагаю добавить сюда и вариант с

kolesov Правильно, многие подходы эффективны. Неужели? Да не может быть! В понедельник - прям другой человек. А где же былая категоричность и самоуверенность? Отпустило немного?
kolesov Прийти ... на пороге чужой методологии, даже не открыв дверь - как бы помягче сказать - неэтично. Трудно сформулировать лучшее описание вашего поведения в этой теме.