Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
Класс classB произведен от класса classA как показано ниже. Как "select * from classB" находит объекты класса classB? Никакого индекса по имени класса нет, перебором все объектов в таблице classA?

Class User.classA Extends %Persistent
{
	Storage Default
	{
	<Data name="classADefaultData">
	<Value name="1">
	<Value>%%CLASSNAME</Value>
	</Value>
	</Data>
	<DataLocation>^User.classAD</DataLocation>
	<DefaultData>classADefaultData</DefaultData>
	<IdLocation>^User.classAD</IdLocation>
	<IndexLocation>^User.classAI</IndexLocation>
	<StreamLocation>^User.classAS</StreamLocation>
	<Type>%Library.CacheStorage</Type>
	}
}


Class User.classB Extends classA
{
	Storage Default
	{
	<Type>%Library.CacheStorage</Type>
	}
}
5 сен 18, 22:27    [21666325]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2583
alatalo,

да, перебирая все объекты. И проверяет класс в хранении.
6 сен 18, 13:39    [21666911]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
Но ведь тогда, без дополнительных индексов по типу, все это имеет сомнительную пременимость поскольку будет серьезно подтормаживать при большом колве записей
6 сен 18, 21:58    [21667519]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
alatalo,

Если не складывать все объекты в одну глобаль то делать select * from ClassA будет невозможно.

Можно класс А сделать абстрактным, тогда объекты подклассов будут попадать в отдельные глобали

Для ускорения поиска по подклассу можно создать extent индекс https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=ROBJ_index_extent
7 сен 18, 08:35    [21667661]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
logist,

про extent не знал, спасибо. Что интересно, Каше его использует только в запросе "select %ID from classB", "select *" предпочитает перебирать все.

А про Abstract не понял. По крайней мере, побавление [Abstact] в декларацию classA ничего не меняет. Storage каждому подклассу свой делать нужно?
7 сен 18, 10:43    [21667812]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 13097
alatalo
А про Abstract не понял. По крайней мере, побавление [Abstact] в декларацию classA ничего не меняет. Storage каждому подклассу свой делать нужно?

Тут кагбэ нужно понять какую цель ты преследуешь так изворачиваясь с классами... Тогда можно было бы предложить путнее решение пока ты не вырыл подземный ход на чердак.
7 сен 18, 10:52    [21667837]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
Блок А.Н.
Member

Откуда: Новосибирск
Сообщений: 3771
alatalo,

Если наследованный класс будет в первую очередь наследоваться от %Persistent, то у него автоматически свое хранилище создастся.
7 сен 18, 14:19    [21668196]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
krvsa,

logist предложил два решения проблемы перебора все таблицы. С extent-ом все понятно, про Abstract - нет
9 сен 18, 20:43    [21669384]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
Блок А.Н.,

да, это понятно
9 сен 18, 20:44    [21669385]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 13097
alatalo, повторюсь, без знания твоей проблемы нет проку что-либо советовать...
Но ты делаешь явно не то.
10 сен 18, 09:09    [21669540]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
Блок А.Н.
Member

Откуда: Новосибирск
Сообщений: 3771
alatalo
krvsa,

logist предложил два решения проблемы перебора все таблицы. С extent-ом все понятно, про Abstract - нет
Ну с abstract все примерно так же, как с первичным наследованием от %Persistent. По идее (емнип), у абстрактного класса не создается хранилище, а значит, у каждого наследованного класса он будет свой). Но это поломает возможность селекта по базовому классу, что вас не устраивает.
Вообще, я бы 10 раз подумал перед тем, как делать единое хранилище для всех классов. Нужно будет намного аккуратнее продумывать индексы и запросы, чтобы работа с ними не просадила быстродействие.
10 сен 18, 11:13    [21669643]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
krvsa,

по дефолту "select * from classB" будет перебирать всю таблицу что не оптимально. Варианта решения два, индекс по контенту или под-классы пишут в отдельные глобали. Вопрос как организовать второй вариант.
11 сен 18, 11:48    [21670729]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
Блок А.Н.,

>По идее (емнип), у абстрактного класса не создается хранилище
Я попробовал, abstract не меняет вообще ничего в плане хранилища
11 сен 18, 11:54    [21670737]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 13097
alatalo, спрошу по другому... Что ты хранить собрался в тех классах?

Нужно не проблему решать, а ее не создавать вовсе.
12 сен 18, 08:43    [21671723]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
alatalo, возможно это поможет
12 сен 18, 16:20    [21672439]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
krvsa,

смотри на это как на абстракную задачу: есть производный класс, нужно сделать select по нему быстрым
13 сен 18, 11:05    [21673216]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
alatalo
Member

Откуда: Хельсинки
Сообщений: 88
doublefint,

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

>Если не закрывать открытый объект ( kill, не %Close()! ), то да - рано или поздно Cache "встанет".
это почему так? Разве каше не должен закрыть объект после того, как умрет последняя ссылка на него?
13 сен 18, 11:17    [21673244]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
krvsa
Member

Откуда: г Волжский
Сообщений: 13097
alatalo
смотри на это как на абстракную задачу: есть производный класс, нужно сделать select по нему быстрым

На задачи по оптимизации не стоит смотреть абстрактно.
Вся оптимизация строится именно на конкретике.

Не хочешь объяснять проблему - твое дело... Тебе с этим мурыжиться.
14 сен 18, 10:19    [21674421]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
alatalo
doublefint,

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

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

Эм.. Это сильно в сторону и не ко мне
14 сен 18, 13:01    [21674633]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
krvsa
Member

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

Ты посмотри на даты тех сообщений. Это было почти 8 лет назад. И нет примера как такового, который "опустит" сервер на "миллионах записей".
Меня лично заверяли, что методы %Close() устарели и ничего не делают. Де нужно использовать именно kill. Что я и сделал...
Никаких "зависаний" не происходило. Хотя конвертировались данные областного значения, переводил с dbf-файлов на классы.
14 сен 18, 13:23    [21674662]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
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."
Похоже, приведенная вами цитата, начиная с какой то версии, утратила актуальность.
14 сен 18, 16:57    [21674938]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
alatalo,


alatalo
Блок А.Н.,

>По идее (емнип), у абстрактного класса не создается хранилище
Я попробовал, abstract не меняет вообще ничего в плане хранилища


Да, в какой то из версий слегка поменялось, нужно еще ClassType снять.

Теперь нужно как то так делать:

Class User.A Extends %Persistent [Abstract, ClassType=""]
{

Property A As %String;

}



Class User.B Extends User.A [ClassType = persistent]
{

Property AAA As %String;

Storage Default
{
<Data name="BDefaultData">
<Value name="1">
<Value>%%CLASSNAME</Value>
</Value>
<Value name="2">
<Value>A</Value>
</Value>
<Value name="3">
<Value>AAA</Value>
</Value>
</Data>
<DataLocation>^User.BD</DataLocation>
<DefaultData>BDefaultData</DefaultData>
<IdLocation>^User.BD</IdLocation>
<IndexLocation>^User.BI</IndexLocation>
<StreamLocation>^User.BS</StreamLocation>
<Type>%Library.CacheStorage</Type>
}

}
20 сен 18, 04:44    [21680225]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
logist
alatalo,

Да, в какой то из версий слегка поменялось, нужно еще ClassType снять.
Теперь нужно как то так делать:



Не "теперь", а при первой(!) возможности - бережет массу сил и времени.
Визг про "все в одной глобали" - он от профанов идет.
Наследование хранимых - часть хорошей архитектуры... если Каше, конечно ;)
(эх, было бы наследование таблиц в MySQL...)
8 окт 18, 10:58    [21697795]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
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"
8 окт 18, 16:22    [21698324]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
было бы наследование таблиц в MySQL...
Есть в PostgreSQL
8 окт 18, 16:25    [21698331]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint
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"


Шаблонное мышление ведет к шаблонным решениям - это даже чем-то хорошо. У "банды" неплохо получилось организовать жизнь массы средней руки проектировщиков и программистов "без задоринки". Задумываться не обязательно. Ну и средний уровень болота уверенно стабилен ;) Религия ведь тоже массу людей с сомнительными зачастую перспективами эффективно превращает в прекрасную нормированную паству (или стадо - тут как посмотреть) - всем от этого только польза! Там правда, банда двенадцати поработала ;)

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

Про грузооборот было, на мой (скромный) взгляд, некогда очень хорошо придумано:

груз -------* строка грузового документа *------- грузовой документ

От груза наследовались контейнеры, насыпные-навалочные, автомобили, нефтепродукты и проч.
От документа - входящие-исходящие-складские, а дальше коносаменты, ордера, поручения, планы и проч. и проч.

Вся информация о грузе собирается одним запросом, контроль связей очень простой и надежный, не нужно особо задумываться при модификациях или изменениях бизнес-требований. Экономится не то, чтобы много времени, а ПРОРВА ВРЕМЕНИ. Удешевляется разработка и, главное, поддержка. И это только один пример.
9 окт 18, 02:49    [21698802]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
... И это только один пример ...
Именно. Т.е. частный случай. Как только показалось, что нашли универсальное решение для всех возможных сценариев ( "наследование наше всё" ) - готовьтесь. А развешивать ярлыки на основании своего частного случая ...
kolesov
... Задумываться не обязательно ...
kolesov
... не нужно особо задумываться ...
Классический kolesov :)
kolesov
От груза наследовались контейнеры, насыпные-навалочные, автомобили, нефтепродукты и проч.
А потом прилетает постановка сделать приложение, работающее только, и только, например, с автомобилями.
9 окт 18, 11:11    [21699005]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint,

Вот скучаю с Вами - сыплете чужими цитатами и своей демагогией. Я показал хорошее решение - многим пригодилось. Вы ЧТО показали?
9 окт 18, 13:55    [21699267]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
... Вы ЧТО показали? ...
Надеюсь, что предупредил - решение имеет свои существенные недостатки. Думать надо всегда. Смешали всё в одну кучу ( хорошая архитектура, ага :) - готовьтесь разгребать. Кстати, чем можете помочь автору темы? :)
Интересный прием использования наследования можно посмотреть у самой ISC, когда базовый класс содержит параметры, по которым генерируется код наследников. Примеров хранимого наследования, навскидку, не припомню - если кто знает, подскажите.
kolesov
сыплете чужими цитатами
Ну, имея опыт общения с вами, вынужден. Для вас ведь никто не является авторитетом, не так ли? :) Если создатели ООП говорят быть осторожнее с наследованием, к кому же прислушаться? :)
kolesov
и своей демагогией
Ну что вы, в этом вы признанный лидер :) "Концентрация на частности", "ad hominem" - перечитайте свои сообщения в этой теме, можно только учиться :)
9 окт 18, 16:42    [21699481]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint,

Приношу извинения, видимо про визг вы приняли на свой счет - а мне вовсе не хотелось переходить на личности - просто фигура речи такая получилась. Согласен, довольно грубо. Еще раз простите. И предлагаю различать дискуссию от обсуждения и осуждения собеседников, ок?
10 окт 18, 01:49    [21699950]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
doublefint
римеров хранимого наследования, навскидку, не припомню - если кто знает, подскажите.


Ну надо заметить, что в коде от ISC хранимых классов вообще не очень много.
10 окт 18, 03:35    [21699966]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
... просто фигура речи такая получилась...
Ой, я вас умоляю, это же ваш фирменный стиль общения - kolesov™ Не пройдет и двух минут... :)
kolesov
... и предлагаю различать ...
Еще раз предлагаю вернуться к теме, автор которой, похоже, воспользовался "хорошим решением". В соседней теме он уже предлагает ISC переделать хранение как раз под этот случай. Так что же ему теперь делать? Расскажите, "многим пригодилось" - рано или поздно, многим тоже понадобится как это из этого выпутываться.
10 окт 18, 11:56    [21700268]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
Как много Вы обо мне знаете? Я вот Вас не дифференцирую из компании, но теперь постараюсь запомнить, где не стоит тратить время ;)
doublefint
Расскажите, "многим пригодилось" - рано или поздно, многим тоже понадобится как это из этого выпутываться.

Вот только там, где это работает уже больше десятка лет и разгребать-то уже некому - программистов каше не осталось. А оно всё работает, наверное, назло злопыхателям!?
10 окт 18, 12:04    [21700277]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
где не стоит тратить время ;)
Вы это уже обещали :) Хм, чуть больше двух минут :)
kolesov
работает, наверное, назло злопыхателям!?
:)
Еще раз, пожалуйста, помогите автору темы. Итак, смешали контейнеры, нефть, автомобили и пр. Работает десятилетиями - данных много. Как теперь работать только с автомобилями. Конкретный вопрос - ваши советы. Очень вероятно, что мы просто не знаем, что известно вам.
10 окт 18, 12:43    [21700340]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
logist
в коде от ISC хранимых классов вообще не очень много.
Но и не мало - см. таблицу Subclasses. Ensemble - по сути, большой пример, написанный ISC, на ее же технологиях.
10 окт 18, 12:49    [21700353]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint
Работает десятилетиями - данных много. Как теперь работать только с автомобилями. Конкретный вопрос - ваши советы. Очень вероятно, что мы просто не знаем, что известно вам.

А так и работать. Так и работали - грузопоток меняется - ушла нефть, больше не создаешь новых грузов этого класса. Хочешь только авто? Не трогай контейнеры - не твоё. Появились банные веники с особым набором характеристик и бизнес-операций(поведения) - грузишь девов разработать новый класс грузов. Причем вся остальная логика и документооборот для веников уже готовы. Проблема в чем?
10 окт 18, 13:04    [21700374]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
Хочешь только авто? ... Проблема в чем?
alatalo
Но ведь тогда, без дополнительных индексов по типу, все это имеет сомнительную пременимость поскольку будет серьезно подтормаживать при большом колве записей
10 окт 18, 13:12    [21700389]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint,
Ну Extent же индекс! Писали выше.
10 окт 18, 13:25    [21700413]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint,
Причем каше, даже если забыть про экстент, все равно проседает не на тех запросах, что "ах все данные в одной глобали" - тут проблемы только в топиках этого форума встречал, но не на практике.
На практике есть класс, в который забыли добавить экстент-индекс, вспомнили лет через 5-ть... а выборки ааатлично шли все это время ;)
10 окт 18, 13:29    [21700425]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint,
Переформулирую в виде максимы: Если есть причины подозревать (бояться и трепетать), что некие данные должны лежать в одной глобали - необходимо отдаться судьбе и их туда таки сложить!
10 окт 18, 13:49    [21700462]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
Переформулирую в виде максимы
Переформулируйте в виде простых списков - есть решение, есть достоинства, есть недостатки
kolesov
некие данные должны лежать в одной глобали
Это просто не наш уровень - классы наше всё. Сформулируйте предпосылки, признаки, условия, при которых стоит использовать хранимое наследование.
alatalo
... без дополнительных индексов по типу ...
kolesov
Ну Extent же индекс!
10 окт 18, 14:42    [21700564]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint,

"- Мама, а как не забеременеть не предохраняясь?"
12 окт 18, 10:23    [21702237]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov, согласен, автор хочет странного.

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

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

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

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

Понимаю, что с этими несущественными недостатки, вы на практике не сталкивались. Но у других могут быть другие обстоятельства, не так ли?
12 окт 18, 10:55    [21702265]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint
kolesov, согласен, автор хочет странного.

Да нет же - у нас в "стране" секса нет!
12 окт 18, 14:36    [21702574]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint
kolesov, согласен, автор хочет странного.

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

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

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

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

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

Вы все смешали, не знаю, почему.
Я не говорил, что все в одной глобали должно... но иногда - да.

Из достоинств еще:
- Общее поведение, часто реализованное ОДИН раз
- Единая структура связей, когда новый член "семьи" уже знает, кто тетка, и за что ему влетит от бати.
- Индивидуальные наборы данных, вместо "общей" таблицы на 800 столбцов (сам видел!) - опять же защита от некорректных транзакций, когда мужику вписывают, какой у него триместр (нечаянно, конечно, но тоже видел и ржал - это кстати плюс говнопроектирования - доставляет улыбнуться)
... это точно не все, повспоминаю еще - стоит отдельной темы

Про недостатки - второй смешной, а по КРУД у меня как всегда свой большой бзик: круд - он ТОЛЬКО для разработчиков, а для бизнес-логики только объекты. У меня одна маруся так схлопотала, когда добавила триггер в систему, что мама не горюй. Но блокировки, sql-доступ и объекты это тоже отдельная тема. Не лочились мои каше-базы НИ РАЗУ за 20 лет. А там сотни миллионов записей на глобал было. Давно не заглядывал, но думаю, что под 2 лярда в кое-каких "табличках" есть.

Ладно, жена наслушалась арбениной живьем и тащит в кабак - не могу отказать )))
12 окт 18, 14:56    [21702603]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

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

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


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

Недостатки:
- Одна глобаль для хранения всех экземпляров-наследников - возможность блокировки всей глобали
- Extent индекс для выборки из конкретного наследника
12 окт 18, 16:46    [21702747]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
doublefint, а чего хотите-то? Отвечать лениво и долго. Вам помощь нужна? Если нет, то стоит прервать разговор - поболтать пальцами удалось вроде ) (гы - я щас за мандарин вместо мышЫ ухватился - "вчерашнее стоит столбом")
13 окт 18, 12:12    [21703221]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

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

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

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

Насколько я понял, в вашем приложении наследование используется для всех трех сущностей предметной области - Документы, Строки, Грузы?
14 окт 18, 07:40    [21703518]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

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

- Блокировок, повторюсь, не встречал. Если у Вас что-то постоянно блокируется, пересмотрите подход. М.б. укоротить транзакции? Блокировки следует ожидать не столько исходя из структуры системы, а скорее из реалий бизнеса - типичная ситуация когда сотня операторов создает и правит одни и те же документы 24х7 - но тут проблема закрывается не столько структурой, сколько логикой - отдельным частным механизмом разруливания конфликтов доступа и блокировок. Остальное - измышления и лишний академизм. Тупее нужно, тупее. Задумываться меньше - тогда будет время на достижение результатов ;)
- Чем экстент-то не угодил? Точно лучше чем заново описывать структуру данных, при появлении новых сущностей типа "документ" или "груз"
- Вы имели в виду накладные расходы, так откажитесь от ООП и делайте все вообще на прямом доступе - я точно придраться не смогу ;)

И приложение не мое - я привел пример из далекого прошлого. На поздних грузовых проектах еще хитрее было разрулено - но с Вами неинтересно говорить - Вы при..в@етесь вместо конструктива. Извините, если это будет последний ответ в теме - правда, не люблю я ононизм.
15 окт 18, 05:09    [21703814]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
kolesov,

Насколько я понял обсуждаем выбор между наследованием и композицией, т.е. практически

Class Car Extends Cargo {}

vs

Class Car Extends %Persistent {

Property Cargo As Cargo [Required];

}

Оба подхода имеют достоинства и недостатки, но на мой взгляд в Каше (Ансамбле/ИРИСе) отличаются незначительно.
15 окт 18, 06:17    [21703820]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
kolesov
Member

Откуда: Владивосток
Сообщений: 748
logist,
Правильно, многие подходы эффективны.
Прийти насрать на пороге чужой методологии, даже не открыв дверь - как бы помягче сказать - неэтично.
Переливать из пустого в порожнее тоже не понимаю зачем - занудненько.
Бесплодное общение получается. Особенно в два мужика ;)
Когда ИРИС ждать-то?
15 окт 18, 07:14    [21703828]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
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 индекс, хранение списка наследования для каждого экземпляра, доп. ключи )
- Одна глобаль для хранения всех экземпляров-наследников - возможность блокировки всей глобали
15 окт 18, 11:48    [21703972]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
Блокировки следует ожидать не столько исходя из структуры системы, а скорее из реалий бизнеса .... когда сотня операторов создает и правит одни и те же документы 24х7 ... проблема закрывается ... отдельным частным механизмом разруливания конфликтов доступа и блокировок.
Да что вы говорите! Готовы переформулировать "максиму" ? :)
15 окт 18, 12:04    [21703993]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
logist
... обсуждаем выбор между наследованием и композицией, т.е. практически
Class Car Extends Cargo {}
vs
Class Car Extends %Persistent {
Property Cargo As Cargo [Required];
}
...
Предлагаю добавить сюда и вариант с
Class Car Extends ( %Persistent, ICargo ){}
15 окт 18, 12:15    [21704005]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
kolesov
Правильно, многие подходы эффективны.
Неужели? Да не может быть! В понедельник - прям другой человек. А где же былая категоричность и самоуверенность? Отпустило немного?
kolesov
Прийти ... на пороге чужой методологии, даже не открыв дверь - как бы помягче сказать - неэтично.
Трудно сформулировать лучшее описание вашего поведения в этой теме.
15 окт 18, 12:25    [21704020]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
doublefint
Достоинства
- Единая структура связей


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

Так что получили три достоинтсва против трех недостатков :)
16 окт 18, 02:42    [21704661]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
doublefint
Class Car Extends ( %Persistent, ICargo ){}


Ну тут нужно более подробно развернуть, потому что обсуждаем схему хранения, а из Вашего примера не понятно какая она в итоге получится.
16 окт 18, 02:43    [21704662]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
kolesov
Когда ИРИС ждать-то?


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

Бесплатная Community Edition в ноябре обещается.
16 окт 18, 02:48    [21704664]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
logist
- Единый ООП интерфейс с возможностью переопределения/расширения базовых методов/триггеров в потомках
Хотелось бы выделить тот момент, что для единого ООП не нужно именно хранимое наследование. Т.е вместо "Car Extend Cargo" - "Car Extend %Persistent, ICargo", где в ICargo могут быть и базовые методы, и генераторы и что угодно.
С триггерами интересней, да. Если не повезет с местом работы, и попадется самовлюбленный начальник-павлин, которому собственное эго перекрывает доступ к мозгу - за них на вас будут тупо орать ;) Тем не менее, это специфический инструмент, к использованию которого надо подходить с осторожностью. Имхо, лучше оставлять схему "анимичной" как можно дольше, насколько это возможно.
Т.е. когда вы планируете структуру с чистого листа, есть большая вероятность, что вы видите предметную область только с одной стороны. По мере появления новых требований, может оказаться что то, что вы принимали за аксиому, таковой не является.
logist
- Более автоматизированное и надежное поддержание целостности.
Да, так и есть. В начале жизненого цикла приложения самое то. Удобно, быстро, надежно. Но бабочку к стене вы прикололи, дальше может не взлететь. Ведь таким образом, через поддержание целостности, вы реализуете бизнес-требования - не может быть Строк без Документа, Груза без Строки и т.д.
logist
Обе проблемы решаемы, но требуют дополнительных усилий.
Да. А вот тратить эти усилия или нет - зависит от конкретной ситуации. Нужно быстродействие - "no more persistent inheritance", "no more relationship", "no more OOP" и т.д. Другая ситуация - другой выбор. Никаких "универсальных" максим.
16 окт 18, 11:34    [21704954]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
MX-9
Member

Откуда: LIBAVA
Сообщений: 381
logist
kolesov
Когда ИРИС ждать-то?


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

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



Можно ли ее как то скачать подобно САСНЕ ,

потом запустить на выполнение ?

и появится кубик синенький
16 окт 18, 21:49    [21705869]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
MX-9,

С WRC можно скачать полную версию или field test - так же как Cache. Бесплатные версии, скорее всего, только в контейнерах и облаках будут.
17 окт 18, 02:56    [21706007]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
logist
Member

Откуда: InterSystems
Сообщений: 244
doublefint
Нужно быстродействие - "no more persistent inheritance", "no more relationship", "no more OOP"


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

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

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


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

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

Согласен, но это - риск при использовании любой технологии. На одном конце - простейшие структуры, которые могут не поддерживать появляющихся новых требований, но которые легко понять и изменить при надобности, на другом - энтерпрайз, многоуровневые разветвленные иерархии и "фабрики фабрик". Я обычно стараюсь выбирать самую простую архитектуру, как показывает практика, даже с учетом возможных затрат на реорганизацию данных, усилий на создание и поддержание такой системы будет тратиться меньше.
17 окт 18, 03:28    [21706019]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
Блок А.Н.
Member

Откуда: Новосибирск
Сообщений: 3771
logist
Но с другой стороны, начинающий разработчик зайдет сюда и увидит - ага, объекты это медленно.
По-моему, как раз скорее происходит обратное. Разработчик видит: вау, объекты, наследование. Все делаем только на них (кажется, я даже в этом топике уже что-то похожее видел). А потом, оказывается, что все работает не так уж быстро, как надеялись, и даже медленнее, чем в реляционных субд. А значит, ваше Каше - не круто, и вообще фу.

logist
Я обычно стараюсь выбирать самую простую архитектуру, как показывает практика, даже с учетом возможных затрат на реорганизацию данных, усилий на создание и поддержание такой системы будет тратиться меньше.
Я тоже пришел к выводу, что если нет четкого плана развития системы, и ты не представляешь, куда ее будет двигать бизнес, лучше делать ее с самым минимальным запасом по архитектуре. Любые заранее заложенные фундаменты непонятно под что, превращаются потом в очень странные рудименты, бесполезные и громоздкие. Лучше писать систему с пониманием того, что завтра произвольную ее часть придется просто выкинуть и написать заново. Согласен с логистом, даже с учетом переделок это скорее всего выйдет дешевле, чем попытка заранее все предусмотреть и сделать подо все заготовки.
17 окт 18, 03:54    [21706026]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
logist
Сила в ... всех трех подходов к данным (Direct / SQL / Objects)
Конечно. Обратите внимание, какой положение занимают триггеры - между Direct и SQL. Прячутся там, валят запросы на ровном месте со странными ошибками :)
logist
... прямой доступ ... для построения сложного квартального отчета ... большой поток входных данных - сохранять их через глобалы ...
Нужно быстродействие - понадобится и более низкоуровневый доступ, да. У каше хорошая скорость вставки.
logist
Я согласен с тем, что категоричные заявления - это плохо.
Необоснованные. Если есть основания так заявлять - почему нет. Заяви, докажи - нет вопросов, большое спасибо и низкий земной поклон. А когда на предложение обосновать начинается - "я устал", "мне лень", "с вами скучно" - хз, что думать.
logist
... ага, объекты это медленно ...
Таки да. Медленно. Что есть то, есть. Но удобно. Но память. Но надо думать.
logist
И наследование - плохо.
Хранимое наследование - плохо. Нет серьезных оснований ( общий список экземпляров-наследников можно получить и другими способами ), чтобы его использовать. Просто наследование - осторожно. Удобно контролировать - да. Расширяется - отлично. Наследник не по Барбаре Лисков - уже неудобно. Ошибка ( изменение ) в базовом - туши свет.
logist
... все что не написано на Ассемблере или на худой конец С - это медленно и отстой.
За такое не агитировал. Наоборот - каше генерирует хороший надежный код для прямого доступа, используйте - Cache Storage, SQL проекции
logist
И я считаю, что в большинстве случаев правильный ответ - "нет".
В большинстве. Как не согласиться.
logist
Я обычно стараюсь выбирать самую простую архитектуру
Ну конечно, KISS же. Хранимое наследование, relationship соответствут ему?
17 окт 18, 12:31    [21706392]     Ответить | Цитировать Сообщить модератору
 Re: select для производного класса  [new]
doublefint
Member

Откуда: Беларусь, Минск
Сообщений: 931
Блок А.Н.
По-моему, как раз скорее происходит обратное. Разработчик видит: вау, объекты, наследование.
Да, "а не забабахать ли мне шаблон МОСТ" - Документ - Строка - Груз. Проблем вроде нет, вон и опытный kolesov криком кричит, мол, лепите никого не слушайте. И только потом выясняется, что объекты то да, есть, но наследование хранимое, и с подводными камнями, и не во всех ситуациях подходит. И у kolesov вместо лозунгов внезапно целая методология с "своими большими бзиками" и специальными хитрыми подсистемами, чтобы все это разруливать. Только он ничего не расскажет, ибо выходные, вино, кабак, а с вами не интересно :)
17 окт 18, 12:53    [21706428]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M Ответить