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

Откуда: Воронеж
Сообщений: 1280
[quot pkarklin]Гм... Курсор объявлен через локальную переменную, которая уничтожается при выходе из скоупа (хп).

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.
[quot]
Ну да, конечно. Привычка, всегда освобождаю сам.

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

[quot pkarklin]
Не понимаю, как из возможности проверять принадлежность записи к "нужному" классу вы сделали вывод, что не используются FK. В полную силу.
[quot]
Имелось в виду, что если FK поле определено в базовой абстрактной сущности (например, "Спецификация табличного документа", ссылка на "Табличный документ") и вы наследуете новые классы, то вам недостаточно ссылаться на Object, необходимо проверять соответствие классов. Иначе, может в результате ошибки программиста оказаться, что запись сущности "Спецификация с/ф" привязана к сущности "Заголовок накладной". Через FK это не сделаешь, нужен триггер или ХП.
13 мар 07, 17:52    [3893867]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
Имелось в виду, что если FK поле определено в базовой абстрактной сущности (например, "Спецификация табличного документа", ссылка на "Табличный документ") и вы наследуете новые классы, то вам недостаточно ссылаться на Object, необходимо проверять соответствие классов. Иначе, может в результате ошибки программиста оказаться, что запись сущности "Спецификация с/ф" привязана к сущности "Заголовок накладной". Через FK это не сделаешь, нужен триггер или ХП.


Эх... Показать бы это все, чтоб было понятно, что и как...

Сообщение было отредактировано: 13 мар 07, 18:04
13 мар 07, 18:04    [3893959]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

Откуда: 8P8C
Сообщений: 2423
WiRuc
Иначе, может в результате ошибки программиста оказаться, что запись сущности "Спецификация с/ф" привязана к сущности "Заголовок накладной". Через FK это не сделаешь, нужен триггер или ХП.

+1, именно этот вопрос я и хотел выяснить, когда говорил о "потере корректности" ссылочной целостности.

И еще, если не секрет :), какого типа идентификатор объектов в ВЕРО? int, bigint(identity) или uniqueidentifier (48 млн - не шутка)?
13 мар 07, 18:04    [3893962]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
bigint
13 мар 07, 18:05    [3893966]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

Откуда: 8P8C
Сообщений: 2423
pkarklin
bigint

Понятно, спасибо. А так хотелось увидеть uniqueidentifier!!!
13 мар 07, 18:09    [3893987]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Сколько ориентировочно потребуется времени на разработку базового функционала ядра?
13 мар 07, 18:14    [3894033]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
Эх... Показать бы это все, чтоб было понятно, что и как...

Из этого я делаю вывод, что все-таки используется FK?
13 мар 07, 18:15    [3894049]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
pkarklin
В нашей системе документы обрабатываются сотнями за раз (например, при зачислении банковской выписки).

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

Для сотни документов это уже 2100 запросов против... тех же 4-х :)
Мой опыт показывает, что скорость выполнения скрипта больше зависит от количества выполненных строк в этом скрипте, чем от количества обработанных записей. Единственная задача, которую мне не удалось заставить быстрее работать на T-SQL в декларативном режиме (одним SELECT) по сравнению с алгоритмическим - это парсинг строки с раздалителями. :) Алгоритмический метод чуть-чуть быстрее - в нем IO вообще отсутствуют.

pkarklin
если в принципе эти 4ре запроса можно написать.


pkarklin
Хм... Вы не поверите, я так и делаю, передаю ид операции во все процедуры.
Странно, что у Вас вообще возникают проблемы с массовой обработкой.
Мне зачастую как раз нехватает исключительно этой ИД в интерфейсе.

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

Остается только решить вопрос с откатами или выходом по ошибке при нехватке прав пользователя - но и это вполне решаемо.
13 мар 07, 18:36    [3894178]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

Откуда:
Сообщений: 181
pkarklin

Абсолютно никакой денормализации. Повторяю, классическая реляционная модель.

Shurgenz
По крайней мере, насколько я понял... в случае иерархии с n-ным уровнем, любые изменения состояния верхнего члена иерархии затрагивает всех потомков, грубо говоря, происходит инсерт апдейт или удаление всех потомков, в зависимости от того, что с предком произошло. Это DML, затратная DML. Но от того, что информация по всему дереву раскрыта, то селекты там простые, и в общем то немедленные от этого.
Извращенная логика, как мне опять же объяснили, разрешается путем добавления индексных полей на том или ином уровне иерархии объекта...


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

DamirS
Поправьте, если не прав.


Вы глубоко не правы.

Кто на ком стоял - не понятно! :)
Итак, здесь обсуждаются 2 "ООП модели": от pkarklin и от вновь пришедшего программиста к Shurgenz - назовём его Автор.
Модель от pkarklin действительно реляционная и очень даже жизнеспособная.
Модель от Автор - абсолютно нежизнеспособная и ведет к загрузке сервера на пустом месте. Еще раз:
Shurgenz
... в случае иерархии с n-ным уровнем, любые изменения состояния верхнего члена иерархии затрагивает всех потомков, грубо говоря, происходит инсерт апдейт или удаление всех потомков, в зависимости от того, что с предком произошло. Это DML, затратная DML.

Вопрос в 1 сообщении звучал:
Shurgenz

Впервые если честно с таким встречаюсь... Все мозги запарил... Кто-нить встречался с таким? Как его отфутболить поумнее? Лажа ведь какая-то

Ответ: действительно лажа. Не надо пытаться реализовывать классическую ООП-модель в SQL.
14 мар 07, 06:27    [3895261]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
Сколько ориентировочно потребуется времени на разработку базового функционала ядра?


Эээ... Ядро уже разработано давно. Так что задача стоит только в наращивании "мяса" на этот скелет. Или Вы что-то другое имели ввиду?

WiRuc
Из этого я делаю вывод, что все-таки используется FK?


Безусловно.

DeColo®es
Мой опыт показывает, что скорость выполнения скрипта больше зависит от количества выполненных строк в этом скрипте, чем от количества обработанных записей.


IMHO, спорное утверждение.

DeColo®es
Странно, что у Вас вообще возникают проблемы с массовой обработкой.


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

Множественная обработка не должна быть самоцелью. Порой, решение с помощью курсора будет иметь выигрыш в производительности по сравнению с навороченным запросом. Это уже из моего опыта. ;)
14 мар 07, 08:28    [3895375]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
Эээ... Ядро уже разработано давно. Так что задача стоит только в наращивании "мяса" на этот скелет. Или Вы что-то другое имели ввиду?

Сколько ориентировочно вашей команде потребовалось человеко-дней на разработку основы ядра? Хочу оценить масштаб работы, если вдруг захочу опробовать такую модель.
14 мар 07, 09:23    [3895504]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
Сколько ориентировочно вашей команде потребовалось человеко-дней на разработку основы ядра? Хочу оценить масштаб работы, если вдруг захочу опробовать такую модель.


Я, кажеться, упоминал, что ядро разработано не мной. Я являюсь его "пользователем", хотя кое-что приходилось "править". Так что сказать о сроках точно не могу. Попробую навести справки. :)
14 мар 07, 09:27    [3895519]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Все-таки, пока мне кажеться, что дальше 3-4 уровня в такой схеме не имеет смысла уходить. Что-то типа 1 - Объект, 2 - абстрактные Справочник, Документ, Табличный документ, 3 - реальные сущности. Дальше уже все больше накладных расходов на поддержание схемы и реальная польза уменьшается.
14 мар 07, 09:37    [3895562]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
Все-таки, пока мне кажеться, что дальше 3-4 уровня в такой схеме не имеет смысла уходить. Что-то типа 1 - Объект, 2 - абстрактные Справочник, Документ, Табличный документ, 3 - реальные сущности. Дальше уже все больше накладных расходов на поддержание схемы и реальная польза уменьшается.


Пример с 5ю уровнями:

Объект->Контракт->Договор хозяйственной деятельности->Авторский договор->Авторский договор (исключительные права)

Причем совсем не обязательно, чтобы каждый уровень был "определен" собственной таблицей. Т.е. дочерний объект может "умещаться" в родительской таблице (по аттрибутике сущности, например), но может иметь свою схему состояния (т.е. свои поведенческие характеристики).
14 мар 07, 09:44    [3895580]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
А вообще предложенная идея, включаяя механизм схем состояния - очень интересная.
Главное - не использовать ее ВЕЗДЕ, где надо и не надо. :)
14 мар 07, 09:48    [3895604]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
Причем совсем не обязательно, чтобы каждый уровень был "определен" собственной таблицей. Т.е. дочерний объект может "умещаться" в родительской таблице (по аттрибутике сущности, например), но может иметь свою схему состояния (т.е. свои поведенческие характеристики).

Это интересный момент. Т.е. не обязательно наследованный объект должен иметь собственную таблицу. Различие сущностей в таблице наверное ведете по классу в Object?
14 мар 07, 10:10    [3895712]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
Пример с 5ю уровнями:

Объект->Контракт->Договор хозяйственной деятельности->Авторский договор->Авторский договор (исключительные права)

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

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
pkarklin
Причем совсем не обязательно, чтобы каждый уровень был "определен" собственной таблицей. Т.е. дочерний объект может "умещаться" в родительской таблице (по аттрибутике сущности, например), но может иметь свою схему состояния (т.е. свои поведенческие характеристики).

Это интересный момент. Т.е. не обязательно наследованный объект должен иметь собственную таблицу. Различие сущностей в таблице наверное ведете по классу в Object?


Есть еще дополнительная таблица - ObjectType - классическое дерево. ;) Object имеет FK на нее.

Сообщение было отредактировано: 14 мар 07, 10:33
14 мар 07, 10:33    [3895828]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DeColo®es
Главное - не использовать ее ВЕЗДЕ, где надо и не надо. :)


А он и не используется "везде". Часть сущностей в системе не являются "объектами", т.е. не имеют отношения к таблице Object.
14 мар 07, 10:37    [3895861]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
ChA
Member

Откуда: Москва
Сообщений: 11319
WiRuc
pkarklin
Пример с 5ю уровнями:

Объект->Контракт->Договор хозяйственной деятельности->Авторский договор->Авторский договор (исключительные права)

Понятно, что при желании можно сделать и 10 уровень наследования, но все-таки с каждым уровнем увеличивается кол-во вставок, необходимых для создании записи в сущности. Нахождение нескольких сущностей в одной таблице уже несколько меняет это дело.
Sorry за вмешательство. Выкиньте из схемы pkarklin первый уровень, т.е., "Объект" и получиться с большой степенью вероятности такое же разбиение при стандартном реляционном подходе. Если, конечно, не идти радикальным путем, когда каждый вид контракта рассматривается как отдельная сущность и тогда появятся 10, если не больше, различных невзаимосвязанных таблиц. И тогда возникают сложности для получения сводных отчетов, сложности ссылочного характера, те самые FK.
Спич к тому, что по большому счету, количество "уровней" при такой схеме может не так уж и сильно отличаться от традиционного подхода.
14 мар 07, 11:35    [3896282]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
ChA
Sorry за вмешательство. Выкиньте из схемы pkarklin первый уровень, т.е., "Объект" и получиться с большой степенью вероятности такое же разбиение при стандартном реляционном подходе. Если, конечно, не идти радикальным путем, когда каждый вид контракта рассматривается как отдельная сущность и тогда появятся 10, если не больше, различных невзаимосвязанных таблиц. И тогда возникают сложности для получения сводных отчетов, сложности ссылочного характера, те самые FK.
Спич к тому, что по большому счету, количество "уровней" при такой схеме может не так уж и сильно отличаться от традиционного подхода.

Я понимаю это несколько по-другому. Объектная модель предполагает расширение аттрибутики от уровня к уровню. Т.е., если моделировать скажем накладные, то наверное была бы такая схема в ООП - Объект->Табличный документ->Товарные накладные->Расходные накладные и Объект->Табличный документ->Товарные накладные->Приходные накладные. Если не заморачиваться с ООП, то обычно Приходные и Расходные накладные это просто 2 разные таблицы (с некоторым подмножеством совпадающих полей), либо вообще 1 таблица с полем, определяющим вид накладной. Т.е. в случае ООП кол-во таблиц для описания сущности будет больше.
14 мар 07, 11:55    [3896444]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
ChA
Member

Откуда: Москва
Сообщений: 11319
WiRuc
Я понимаю это несколько по-другому. Объектная модель предполагает расширение аттрибутики от уровня к уровню. Т.е., если моделировать скажем накладные, то наверное была бы такая схема в ООП - Объект->Табличный документ->Товарные накладные->Расходные накладные и Объект->Табличный документ->Товарные накладные->Приходные накладные. Если не заморачиваться с ООП, то обычно Приходные и Расходные накладные это просто 2 разные таблицы (с некоторым подмножеством совпадающих полей), либо вообще 1 таблица с полем, определяющим вид накладной. Т.е. в случае ООП кол-во таблиц для описания сущности будет больше.
То, что больше, сомнению не подвергалось, если только не перейти на радикальный EAV, там вообще число таблиц может быть просто фиксировано один раз и навсегда.
Упомянутая Вами схема с накладными действительно проще, но до тех пор, пока не требуются связи между документами, при которых могут возникать ссылки на совершенно разные сущности-документы, при этом, как правило, либо появляются ссылочная целостность на сложных триггерах, учитывающих допустимость даного значения поля-ссылки, и при появлении каждого нового типа документов их придется переписывать, либо куча полей, по которым будет возможно FK, но, возможно, только по одному из них, что потребует дополнительных проверок, если хотим "по честному". И при этом, новой сущность опять же потребует модификацию схемы, меняя количество полей и корректируя проверки.
Сводная отчетность также не добавляет простоты, когда приходиться через union объединять стада разношерстных таблиц, и при появлении новых сущностей опять же будем вынуждены ее переписывать.
Единственный, IMHO, здравый путь для борьбы с этим комом проблем, введение суперсущностей, той или иной степени абстрактности. И в результате, незаметно для себя мы получаем ту же самую иерархию, ну может быть на один-два уровня пониже.
Понятно, что если мы автоматизируем какой-нибудь магазинчик, склад, да мало ли еще чего, то такой подход возможно будет эквивалентом пушки по воробьям. Но когда речь идет об автоматизации крупного холдинга, к примеру, то без иерархии сущностей работы будет больше, IMHO.
В конце концов, компьютеры и сервера должны работать, облегчая нашу жизнь, а не мы все время искать пути, как бы поменьше их загрузить Хотя, допускаю, что мысль выглядит спорной.
14 мар 07, 12:28    [3896706]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
ChA
Упомянутая Вами схема с накладными действительно проще, но до тех пор, пока не требуются связи между документами, при которых могут возникать ссылки на совершенно разные сущности-документы, при этом, как правило, либо появляются ссылочная целостность на сложных триггерах, учитывающих допустимость даного значения поля-ссылки, и при появлении каждого нового типа документов их придется переписывать, либо куча полей, по которым будет возможно FK, но, возможно, только по одному из них, что потребует дополнительных проверок, если хотим "по честному". И при этом, новой сущность опять же потребует модификацию схемы, меняя количество полей и корректируя проверки.

Для описания необязательных связей между документами достаточно будет в большинстве случаев завести отдельную таблицу связей типа DocLinks с отношением M:M. Конечно, тут уже о проверке ссылочной целостности на FK придется забыть. И я не уверен, что в схеме ООП, эта таблица будет отсутствовать. А при автоматизации все упирается в соотношение быстродействие:гибкость. Хотите максимум производительности - будете рисовать отдельные сущности, ничего не попишешь. Палка о двух концах.
14 мар 07, 12:59    [3896916]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
ChA
Member

Откуда: Москва
Сообщений: 11319
WiRuc
Хотите максимум производительности - будете рисовать отдельные сущности, ничего не попишешь. Палка о двух концах.
Совершенно верно. Собственно, в этом топике суть была высказана на первой странице, IMHO. Остальное из разряда "верю-не верю", "нужно-не нужно". Нужна гибкость, настраиваемость, минимум вмешательств в схему БД при появлении новых сущностей, выбираете один подход, нужна максимальная производительность - другой. Скажем биллинг я лично не рискнул бы делать по объектно-подобной модели. Но есть достаточно много документоориентированных областей, где она, возможно, может оказаться более предпочтительной.
14 мар 07, 13:13    [3897006]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
ChA
WiRuc
Хотите максимум производительности - будете рисовать отдельные сущности, ничего не попишешь. Палка о двух концах.
Совершенно верно. Собственно, в этом топике суть была высказана на первой странице, IMHO. Остальное из разряда "верю-не верю", "нужно-не нужно". Нужна гибкость, настраиваемость, минимум вмешательств в схему БД при появлении новых сущностей, выбираете один подход, нужна максимальная производительность - другой. Скажем биллинг я лично не рискнул бы делать по объектно-подобной модели. Но есть достаточно много документоориентированных областей, где она, возможно, может оказаться более предпочтительной.


Я тоже к этому склоняюсь

Если схема будущей БД планирется быть более менее статичной и малоизменяемой, то лучше работать по классической схеме. Редко ведь когда приходится (в большинстве случаев) вносить значительные изменения в структуру БД и в функциональность. Чаще всего из того с чем мне приходится и приходилось работать затрагивало обычно небольшую часть структуры и функциональности, что легко описывалось несложными DDL/DML скриптами (аля патчами).
14 мар 07, 15:23    [3898021]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить