Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Мдя. Видимо объясняльшик из меня плохой. Хотя вот так, пальцем трудно что-то показать. Надо бы со структурой бд, с кодом. GreenSunrise, WiRuc - процу отправил Вам на мыло. Но, думаю, что она только добавит вопросов.
13 мар 07, 15:17    [3892635]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
pkarklin
Ничего подобного не происходит. Никаких DML - упаси господи.


При изменении состояния объекта никаких DML?
13 мар 07, 15:18    [3892647]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

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

А мне можно? Временно открыл видимость... Потом закрою, а то спам всякий все больше стал сыпаться
13 мар 07, 15:20    [3892661]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Shurgenz
pkarklin
Ничего подобного не происходит. Никаких DML - упаси господи.


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


Нет. Никакие действия в клиентском приложении не приводят к модификации структуры бд.
13 мар 07, 15:21    [3892667]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
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.

При чем здесь структура? Извините
13 мар 07, 15:23    [3892685]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
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, как красная тряпка. Ну, уж, извините.
13 мар 07, 15:29    [3892734]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

Откуда: 8P8C
Сообщений: 2423
LR
Вы можете поделиться с общественностью структурой таблицы dbo.Object? ;)

Понимаю, что эта структура является результатом многолетнего опыта и немалых человекочасов изысканий/тестирования/переделок/проч., поэтому не настаиваю :)

Как и WiRuc, подозреваю, что это - ВЕРО :)
Поэтому позволю себе задать еще один вопрос. Из статьи о ВЕРО: "Реестр содержит информацию об уникальном идентификаторе объекта, типе, состоянии, правах доступа и др., обеспечивая...".
Правильно ли я понимаю, что "Реестр" - это не одна таблица (а несколько базовых)?
13 мар 07, 15:30    [3892749]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 Shurgenz

Но только в случаи изменения состояния объекта (точнее сказать экземпляра класса) DML касаются "только его".
13 мар 07, 15:31    [3892753]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
LR
LR
Вы можете поделиться с общественностью структурой таблицы dbo.Object? ;)

Понимаю, что эта структура является результатом многолетнего опыта и немалых человекочасов изысканий/тестирования/переделок/проч., поэтому не настаиваю :)

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


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

Вы совершенно правильно понимаете - ЕРО это не одна таблица, а довольно приличная куча объектов бд и не менее приличная куча кода - это ядро системы, позволяющее разработчику сконцентрироваться на прикладных задачах. Но, это один из возможных вариантов, а не "серебряная пуля".
13 мар 07, 15:37    [3892806]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

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

А мне можно? Временно открыл видимость... Потом закрою, а то спам всякий все больше стал сыпаться

Если можно, и мне?
13 мар 07, 15:40    [3892828]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
LR
Если можно, и мне?


Коллеги, ну что она вам даст? Проца из 250 строк, в которой идет вызов 1.5 десятков других проц и кучи функций.
13 мар 07, 15:43    [3892848]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

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

Что-то стало понятнее... Непонятно только, почему это подается как ООП, наследование и все такое. Практически то же самое можно сделать с самым обычным реляционным подходом.
13 мар 07, 15:46    [3892875]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
GreenSunrise
pkarklin, а вы такую систему имели в виду? У меня сложилось ощущение, что нет.


Конечно же, нет!!! У меня классические сущности с классическими аттрибутами. Т.е. аттрибуты "Дата" и "Номер" сущности "Документ" - это поля DocDate и DocNumber таблицы Document (базовый класс документа), но, которая отношением 1-к-1 связана с таблице Object.
13 мар 07, 15:50    [3892917]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
А мне ответить про насущную необходимость универсального поиска разнотипных сущностей и единого списка статусов?

Просто я и правда пока не вижу необходимости существования единой базовой таблицы.
Общей список статусов может содержать только 1 общий для всех - "удален, больше не нужен". Все остальные статусы уж больно специфичны и практически "не пересекаются".
13 мар 07, 15:56    [3892960]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


Еще раз повторюсь - используется классический реляционный подход. А вот поведенческие характеристики системы выглядят, как будто она реализована с использованием ООП. Т.е. выполняются действия для объектов, которые не существуют на момент разработки ядра. Объекты могут иметь характеристики и значения, которые появятся "потом". Даже функция ObjectIs(ID, 'ClassName') ведет себя аналогично дельфиской is - т.е. с учетом наследования.
13 мар 07, 15:59    [3892984]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

Единый поиск разнотипных сущестной - не самоцель, хотя такой поиск и существует. В прочем, как и существуют специализированные "поиски" для определенных типов сущностей.
13 мар 07, 16:04    [3893024]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Понятно, спасибо. В общем, было интересно ознакомиться с наличием других подходов к проектированию, но на данном этапе развития СУБД с практической точки зрения для меня они неинтересны.
13 мар 07, 16:22    [3893152]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

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

pkarklin
Единый поиск разнотипных сущестной - не самоцель, хотя такой поиск и существует.
А для чего им пользуются-то? И что показывается в "сводной табличке"? Какие общие колонки могут быть у сущностей "Контрагент" и "Документ"?

ЗЫ Просто Вы написали про это, как про достоинства. Но пока непонятно, в чем достоинство-то?
13 мар 07, 16:27    [3893200]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
2 pkarklin
Спасибо за пример.
Чуда не произошло, собственно, именно этого я и ожидал. Отход от работы со множествами и переход к процедурной обработке с помощью курсоров. И мне слабо верится, что данный подход может обеспечить равную производительность с "класичесским".
И, насколько, я понимаю FK вы не пользуетесь или пользуетесь ограниченно, т.к. необходимо проверять принадлежность записи к "нужному" классу. А отсутствие FK отрицательно сказывается на возможностях оптимизатора.
Именно всю эту базовую рутину - журнализация, схемы состояний, и т.д. можно спокойно реализовать на таком же уровне без введения родительской таблицы Object. При этом со всеми остальными сущностями работу можно организовывать в классическом варианте.
И еще, использование в селекте dbo.ObjectIs(O.ID,'ExtValueEMail') = 1 опять намекает на переход к процедурному типу программирования.
Конечно, подход может быть интересен с точки зрения упрощения реализации бизнес-логики. Очевидно, надо поработать с ним некоторое и проникнуться всей мощью и гибкостью, чтобы оценить все возможности. Но на первый взгляд, наличие кодогенераторов и базового фреймворка сводят на нет все преимущества ООП в реляционной БД.
P.S. Бросилось в глаза, что вы не закрываете в конце процедуры курсор @MM.
13 мар 07, 16:44    [3893310]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

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


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

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

ЗЫ. Если Вы считаете существование такого поиска абсолютна не нужным, я не буду Вас ни в чем убеждать. В конечно итоге - сквозная идентификация объекта в системе в одной таблице это только предпосылка для реализации всего остального функционала ядра.
13 мар 07, 16:50    [3893349]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
P.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 опять намекает на переход к процедурному типу программирования.
Конечно, подход может быть интересен с точки зрения упрощения реализации бизнес-логики. Очевидно, надо поработать с ним некоторое и проникнуться всей мощью и гибкостью, чтобы оценить все возможности. Но на первый взгляд, наличие кодогенераторов и базового фреймворка сводят на нет все преимущества ООП в реляционной БД.


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

Сообщение было отредактировано: 13 мар 07, 17:38
13 мар 07, 17:26    [3893652]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
pkarklin
Какой список? Кто с кем не связан, но должен быть связан, по Вашему, по смыслу? И, причем тут администрирование?
Списки статусов для разных сущностей не связаны по смыслу. То есть для каждой сущности статус это некий "свой" аттрибут со "своей" смысловой нагрузкой.

Администрирование - это обшщий интерфейс управления схемами статусов.

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

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

ЗЫ На самом деле многие идеи очень интересны. Просто лично мне пока непонятно, зачем привязывать ВСЕ идеи ко всем "объектам".
13 мар 07, 17:30    [3893676]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

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


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

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


Ну, что ж, мне тоже не сразу стало все понятно. Но заложенные в систему идеи деуствительно интересны.
13 мар 07, 17:38    [3893747]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
pkarklin
Вы готовы со сто процентной уверенностью гарантировать, что "раскрытии" этого кода хп на множественную обработку даст выигрыш. Я нет. Я на 100% не верен, что это можно в принципе раскрыть до "множественной" обработки.
Все зависит от задачи. Если в каждой операции обрабатывается 1-2 документа, не больше, то тогда раскрывать особо смысла нет.
Но вот если при одной операции документы обрабатываются десятками....

Да и не просто десятками, а по схеме:
1 документ ->
2 проводки ->
3 счета (один счет корреспондирует с 2-мя другими в разных проводках) ->
15 счетов верхнего уровня (по 5 на каждый счет) и т.д.

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

Передо мной стоит как раз задача оптимизации как раз такого щасстя.
Работы много, учитывая, что разные типы документов обрабатываются по-разному, но ничего невозможного нет. Насчет возможности раскрытия - как правило, так или иначе есть ИД некой операции, в рамках которой меняются те же документы. Ну вот эту ИД во все процедуры и передавать.
13 мар 07, 17:43    [3893793]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DeColo®es
Но вот если при одной операции документы обрабатываются десятками....


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

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


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

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


Хм... Вы не поверите, я так и делаю, передаю ид операции во все процедуры.
13 мар 07, 17:49    [3893846]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить