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

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

Откуда: Беларусь, Минск
Сообщений: 932
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

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

Откуда: Беларусь, Минск
Сообщений: 932
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

Откуда: Беларусь, Минск
Сообщений: 932
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

Откуда: Беларусь, Минск
Сообщений: 932
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
Сообщений: 386
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

Откуда: Беларусь, Минск
Сообщений: 932
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

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