Мдя. Видимо объясняльшик из меня плохой. Хотя вот так, пальцем трудно что-то показать. Надо бы со структурой бд, с кодом. GreenSunrise, WiRuc - процу отправил Вам на мыло. Но, думаю, что она только добавит вопросов.

Shurgenz pkarklinНичего подобного не происходит. Никаких DML - упаси господи.


При изменении состояния объекта никаких DML?

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

Shurgenz pkarklin Shurgenz pkarklinНичего подобного не происходит. Никаких DML - упаси господи.


При изменении состояния объекта никаких DML?

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

Data Manipulation Language (DML) is a family of computer languages used by computer programs or database users to retrieve, insert, delete and update data in a database.

При чем здесь структура? Извините

Сорри, тут я ступил. Привидилось DDL, как красная тряпка. Ну, уж, извините.

2 Shurgenz

Но только в случаи изменения состояния объекта (точнее сказать экземпляра класса) DML касаются "только его".

LR LRВы можете поделиться с общественностью структурой таблицы dbo.Object? ;)
Понимаю, что эта структура является результатом многолетнего опыта и немалых человекочасов изысканий/тестирования/переделок/проч., поэтому не настаиваю :)

Как и WiRuc, подозреваю, что это - ВЕРО :)
Поэтому позволю себе задать еще один вопрос. Из статьи о ВЕРО: "Реестр содержит информацию об уникальном идентификаторе объекта, типе, состоянии, правах доступа и др., обеспечивая...".
Правильно ли я понимаю, что "Реестр" - это не одна таблица (а несколько базовых)?

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

Вы совершенно правильно понимаете - ЕРО это не одна таблица, а довольно приличная куча объектов бд и не менее приличная куча кода - это ядро системы, позволяющее разработчику сконцентрироваться на прикладных задачах. Но, это один из возможных вариантов, а не "серебряная пуля".

LRЕсли можно, и мне?

Коллеги, ну что она вам даст? Проца из 250 строк, в которой идет вызов 1.5 десятков других проц и кучи функций.

GreenSunrise pkarklin, а вы такую систему имели в виду? У меня сложилось ощущение, что нет.

Конечно же, нет!!! У меня классические сущности с классическими аттрибутами. Т.е. аттрибуты "Дата" и "Номер" сущности "Документ" - это поля DocDate и DocNumber таблицы Document (базовый класс документа), но, которая отношением 1-к-1 связана с таблице Object.

GreenSunriseЧто-то стало понятнее... Непонятно только, почему это подается как ООП, наследование и все такое. Практически то же самое можно сделать с самым обычным реляционным подходом.

Еще раз повторюсь - используется классический реляционный подход. А вот поведенческие характеристики системы выглядят, как будто она реализована с использованием ООП. Т.е. выполняются действия для объектов, которые не существуют на момент разработки ядра. Объекты могут иметь характеристики и значения, которые появятся "потом". Даже функция ObjectIs(ID, 'ClassName') ведет себя аналогично дельфиской is - т.е. с учетом наследования.

DeColo®esА мне ответить про насущную необходимость универсального поиска разнотипных сущностей и единого списка статусов?


Единого списка статусов не существует. Схема состояний (объект) состоит из состояний (объектов). Каджый объект может иметь одну единственную схему состояний.

Единый поиск разнотипных сущестной - не самоцель, хотя такой поиск и существует. В прочем, как и существуют специализированные "поиски" для определенных типов сущностей.

DeColo®esНу тогда это не такое уж и достоинство. Так, очередной элемент EAV. В одном списке хранятся фактически несколько, никак не связанных по смыслу. Объединенных только общей системой администрирования. Достоинства понятны, недостатки - тоже: независимо от необходимости для конкретного класса, будет проходить проверка возможности смены статуса (наверняка еще и в разрезе системы прав на конкретную смену этого статуса, а возможно еще и с попыткой анализа истории типа "Статус может быть изменен с А на B только при условии, что раньше никогда не встречался статус С")

Какой список? Кто с кем не связан, но должен быть связан, по Вашему, по смыслу? И, причем тут администрирование? Если на смене статусов и событий до\после закладывается бизнес-логика системы.

DeColo®esА для чего им пользуются-то? И что показывается в "сводной табличке"? Какие общие колонки могут быть у сущностей "Контрагент" и "Документ"?

У все обектов есть один общий аттрибут - нименование, который заполнятеся для каждого типа объекта индивидуально, для контрагента - это юр. наименование, для документа № от дата. и т.п. Поиск любого объекта возможен только по этому сведенному наименованию.

В свойдной табличке показыается тип объекта, состояние, наименование, описание.

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

WiRucP.S. Бросилось в глаза, что вы не закрываете в конце процедуры курсор @MM.

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

If a name or variable is the last one referencing the cursor, the cursor is deallocated and any resources used by the cursor are freed.

WiRucОтход от работы со множествами и переход к процедурной обработке с помощью курсоров. И мне слабо верится, что данный подход может обеспечить равную производительность с "класичесским".

Вы так приподносите, что я в курсоре значению поля записей 2 прибавляю. ;) Тогда м.б. определимся, что есть "классический" подход в Вашем понимании. Если бизнес логика реализована на хп, например, проведение документа (в которой делается ой как много (проверка допукстимости корреспондеции счетов, да много чего, включая то же логгирование), а не два тупых инсерта в таблицу проводок) и мне надо провести 100 документов, чем, по Вашему плох подход с курсором? Вы готовы со сто процентной уверенностью гарантировать, что "раскрытии" этого кода хп на множественную обработку даст выигрыш. Я нет. Я на 100% не уверен, что это можно в принципе раскрыть до "множественной" обработки.

WiRucИ, насколько, я понимаю FK вы не пользуетесь или пользуетесь ограниченно, т.к. необходимо проверять принадлежность записи к "нужному" классу. А отсутствие FK отрицательно сказывается на возможностях оптимизатора.

Не понимаю, как из возможности проверять принадлежность записи к "нужному" классу вы сделали вывод, что не используются FK. В полную силу.

WiRucИменно всю эту базовую рутину - журнализация, схемы состояний, и т.д. можно спокойно реализовать на таком же уровне без введения родительской таблицы Object. При этом со всеми остальными сущностями работу можно организовывать в классическом варианте.

Готов ознакомится с вариантом решения. Пусть даже в таком корявом изложении, какое получилось у меня.

WiRucИ еще, использование в селекте dbo.ObjectIs(O.ID,'ExtValueEMail') = 1 опять намекает на переход к процедурному типу программирования.
Конечно, подход может быть интересен с точки зрения упрощения реализации бизнес-логики. Очевидно, надо поработать с ним некоторое и проникнуться всей мощью и гибкостью, чтобы оценить все возможности. Но на первый взгляд, наличие кодогенераторов и базового фреймворка сводят на нет все преимущества ООП в реляционной БД.

Да, процедурное программирование.Но, простите, кодогенераторы делают что-то другое? Тогда пардон... Еще раз говорю нет тут никакого ООП. Просто реализация модели как бы обладает свойствами, присущими ООП.

DeColo®esА если - нет? Ведь все равно проверка хотя бы необходимости дальнейшей проверки статусов нужна. А если привязать себя намертво к логике именно смены статусов, решение некоторых тривиальных задач получится... перемудреным.

Состояния, их смены, "триггерные" процедуры до\после - вот место приложения труда разработчика бизнес-логики. Так что Ваше "А если - нет?" мне не совсем понятно. Если нет - то все наше обсуждение - беспредметный треп.

DeColo®esИ вообще - нет понятия "бизнес-логика системы". Есть понятия просто "бизнес-логика" (требования бизнеса к обработке данных) и логика системы - как это реализовано. И второе должно подстраиваться под первое, а не наоборот.

К словам начинаете придераться. Термин "бизнес-логика, заложенная в систему" Вас устроит? На предмет что под что должно подстраиваться. Вам бы чуток поработать на внедрении западных систем. Когда заложенная в них бизнес-логика считается "лучшей практикой" и под нее подстраиваются. :)

DeColo®esНа самом деле многие идеи очень интересны. Просто лично мне пока непонятно, зачем привязывать ВСЕ идеи ко всем "объектам".

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

DeColo®esНо вот если при одной операции документы обрабатываются десятками....

В нашей системе документы обрабатываются сотнями за раз (например, при зачислении банковской выписки).

DeColo®esТо есть либо (условно, конечно) 21 запрос на КАЖДЫЙ документ, либо - всего 4 независимо от количества документов.

А вот тут бабушка на двое сказала. Далеко не факт, что 21 запрос, обрабатывающий 1 запись отработают медленне, чем 4 запроса, обрабатывающие более одной записи, если в принципе эти 4ре запроса можно написать.

DeColo®esНасчет возможности раскрытия - как правило, так или иначе есть ИД некой операции, в рамках которой меняются те же документы. Ну вот эту ИД во все процедуры и передавать.

Хм... Вы не поверите, я так и делаю, передаю ид операции во все процедуры.