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

Откуда: Питер
Сообщений: 1938
ChA
Shurgenz
Резать, к чортовой матери, не дожидаясь перитонита С такой схемой он вас похоронит. Наверняка практического опыта в реализации подобной подхода у него нет, и учиться он будет на вас, а это может дорого стоить.


да нет же, говорит:

автор
моя прежняя работа это ***

Документов миллионы, их атрибутов миллиарды и все это работает в режиме реального времени.

Откуда убежденность в том что это тормоза? Тормоза появляются тогда, когда нужно писать извращенные запросы.

Я пока работал с объектной моделью, то даже не слышал про оптимизацию запросов, потому что не было необходимости.

Все запросы очень простые были и работали на ура.


И млин... если он собирается все переделывать

автор
А наследование – оно помогает везде, в любом приложении.
Я уже описал в одном из первых писем. И это все будет использоваться в системе.
Не все сразу, конечно


То я не против, пусть имплементит... локально... А то я все равно не врублюсь... где именно у нас это можно воплотить
12 мар 07, 16:03    [3888094]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Бывший казначей
Guest
Да ладно вам!
На самом деле действительно все зависит от решаемой задачи!
Я сопровождал (разрабатывали другие) программулину с подобной архитектурой.
НО!
1 - Иерархия классов там была двухуровневой (финансовые документы - пратежные поручения, реестры и т.п.)
2 - реализация была чуть менее ортодоксальной - на уровне представлений и хранимок все-таки прослеживался скорее РСУБД-шный подход, что в сочетании с такой структурой таблиц действительно обеспечивало высокую гибкость.
3 - это было в системе Федерального казначейства, где технологии меняются нуочень часто, поэтому такая гибкость была ЖИЗНЕННО НЕОБХОДИМА!
4 - каждый год заводилась новая база данных (бюджет у нас пока еще на один календарный год принимают) с переносом остатков из прошлогодней базы.

А автору действительно следует во-первых, объяснить, что прежде всего надо придерживаться принятого корпоративного стандарта. Во-вторых надо рассматривать применимость предлагаемой структуры к конкретной задаче. А в-третьих нужно прикинуть трудоемкость перехода на новую структуру данных.
12 мар 07, 16:05    [3888108]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


Тоже саммое сказал и я, когда впервые увидел такой подход.

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


Не факт - работа системы ни есть вставка в одну таблицу. ;)

WiRuc
У вас промышленная эксплуатация такой системы? Давайте тогда подробности...


Что Вас конкретно интересует?
12 мар 07, 16:07    [3888116]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


Золотые слова. Именно такая реализация и используется.
12 мар 07, 16:09    [3888120]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
ChA
Member

Откуда: Москва
Сообщений: 11319
Shurgenz

автор
моя прежняя работа это ***

Документов миллионы, их атрибутов миллиарды и все это работает в режиме реального времени.

Откуда убежденность в том что это тормоза? Тормоза появляются тогда, когда нужно писать извращенные запросы.

Я пока работал с объектной моделью, то даже не слышал про оптимизацию запросов, потому что не было необходимости.

Все запросы очень простые были и работали на ура.
где именно у нас это можно воплотить
Ну, если сверху дали добро, пусть применяет, от Вас, в данном случае, похоже, ничего не зависит.
Теперь касательно речи автора. Что такое извращенные запросы в его терминологии ? У нас, например, при подобном подходе иногда такие запросы получаются, что мама не горюй. И именно в связи с оптимизацией. Я, конечно, не знаю, что там за миллионы с миллиардами, но похоже, что логика ранее была более чем простой, если судить по схеме. У нас например, бухучет живет с самой, что ни на есть извращенной логикой, которая только может придти "гениям", которые периодически ставят всю страну на уши своими новыми законами, правилами и прочей фигней. И, Боже, как это задолбало
12 мар 07, 16:17    [3888162]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
Что Вас конкретно интересует?

Общее описание: что за система (предметная область), какая глубина иерархии, как реализованы массовые операции над сущностями, количество пользователей, количество транзакций в секунду, были ли проблемы с производительностью и как их решали.
Больше всего меня интересует Ваше мнение в сравнении с традиционным подходом. Вот скажем, реализовали бы такую систему в стандартном варианте, в чем бы мы выиграли, а в чем проиграли.
12 мар 07, 16:21    [3888178]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
Cha:

Да вот и у нас не слаще:

1. Передача произвольного количества параметров в процедуру (реализовал как массив с элементами фиксированной длины)
2. Нечеткая связь многие-ко-многим между одной таблицей с двумя другими...
Типа некий объект (таблица, не путать с ООП объектом!!:)), который связывается с пользователем, либо с группой пользователей

п.2 был сразу назван ущербным. Поскольку я для развязки использовал не 2, а одну таблицу... Где оба внешних ключа были: один на группу, другной на юзеров, оба NULLable... Мож я был неправ, но правильно накатив индексы, ключи, и подумавши написав процедуры, получил в общем то не оч плохой вариант, с неплохими, на мой взгляд, планами выполнения.

Вот, пытаюсь выяснить теперь, как при ООП это все разрулить
12 мар 07, 16:26    [3888209]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Бывший казначей

1 - Иерархия классов там была двухуровневой (финансовые документы - пратежные поручения, реестры и т.п.)
2 - реализация была чуть менее ортодоксальной - на уровне представлений и хранимок все-таки прослеживался скорее РСУБД-шный подход, что в сочетании с такой структурой таблиц действительно обеспечивало высокую гибкость.

Ну, это совсем другое дело. Разнесение сущностей на 1-1 в принципе практикуется (скажем, контрагенты -> физ.лица, юр. лица).
Другое дело, если мы БД будем реализовывать как классы в .NET - object и погнали наращивать иерархию.
12 мар 07, 16:27    [3888216]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Например, как мне решить такую задачу: Есть 3-х уровневая иерарахия. Для итоговой сущности я хочу сделать выборку по 3 полям, по одному полю из каждого уровня иерархии. Каждое условие по отдельности имеет низкую селективность, а вместе они дают высокую селективность. Как мне реализовать выборку с достаточной производительностью? На обычной таблице это решается путем построения составного индекса.
12 мар 07, 16:40    [3888279]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
pkarklin
Что Вас конкретно интересует?

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


1. Ну, скажем так - вся логистика + часть документа оборота + часть бухгалтерии + бюджетирование + еще кой-чего по-немногу. Система то развивается. :)
2. Глубина - не более 7.
3. Все реализовано через хп.
4. Пользователей (работающих) не много - около 100, но большую часть работы (читай нагрузки) создают роботы.
5. В среднем (по перфоманс монитору) - 30.
6. Пробемы с производительностью в основном связаны не с выбранной архитектурой.

При реализации "стандартным" подходом сильно бы проиграли на сроках реализации решений, ибо огромная часть логики реализована в ядре системы. На производительности -такой подход врядли сильно сказался бы отрицательно, даже, IMHO, наоборот. Ибо "узких мест" - единицы, а они не разбросаны по все системе и их легче "отловить" и оптимизировать.
12 мар 07, 16:42    [3888303]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


Любая сущность в системе (состоящая из от 1 до N таблиц) представлена представлением. (Прошу прощения за каламбур). Нет прямого доступа к таблицам. Индекс будет построен на представлении.
12 мар 07, 16:45    [3888316]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
Ну, это совсем другое дело. Разнесение сущностей на 1-1 в принципе практикуется (скажем, контрагенты -> физ.лица, юр. лица).


Ну, так и сделано, в принципе, только за одним исключением, что есть одна единственная "родительская" сущность.
12 мар 07, 16:47    [3888328]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

Откуда: 8P8C
Сообщений: 2423
Можно еще поискать обсуждения по теме на форуме "Разработка информационных систем", вот одно из таких(эпических):

Если у наследника не будет своей процедуры, то вызовется процедура родителя

И? Куды тут ООП_механику_данных?

ВЕРО - единый реестр объектов
12 мар 07, 16:56    [3888398]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
Тема ООП в реляционных СУБД практически неисчерпаема. Каждый свежеиспеченный разработчик баз данных бросается создавать обьектную модель. Наиболее грамотные из них через некоторое время, поломав себе зубы и набив шишки (это в лучшем случае), выстраивают нечто вроде
автор
... реализация была чуть менее ортодоксальной - на уровне представлений и хранимок все-таки прослеживался скорее РСУБД-шный подход, что в сочетании с такой структурой таблиц действительно обеспечивало высокую гибкость.


Только к этому моменту, это уже становится совсем не ООП.
Ибо классовый подход ориентирован на экземпляры. На единицы. А реляционные СУБД, как известно - на отношения множеств. Скрести коня и трепетную лань никак не получается. Если бы было все так просто, поддержка ООП появилась бы уже 2000-м.

А некие системы, ориентированные на гибкость, на хранение и доступ данных произвольного вида - то, о чем пишет pkarklin - разумеется, да, существуют почти в каждой крупной ИС. Сделать такую штуку с удачным балансом производительности/гибкости трудно, но можно - но к инкапсуляции, полиформизму и наследованию она будеть иметь очень далекое отношение.

Nobody faults but mine... (LZ)
12 мар 07, 16:57    [3888407]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
LR
ВЕРО - единый реестр объектов


Ну, тогда уж так: Ставка на ВЕРО ;)
12 мар 07, 17:00    [3888428]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

Откуда: 8P8C
Сообщений: 2423
pkarklin
LR
ВЕРО - единый реестр объектов


Ну, тогда уж так: Ставка на ВЕРО ;)

О, спасибо, этот вопрос интересует уже давно, уже читаю :)
12 мар 07, 17:22    [3888588]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Вдрызг
Member

Откуда: Минск
Сообщений: 369
Работал с БД, структура которой отчасти напоминала обсуждаемую схему. Система документооборота. Сходство было в том, что тоже были объекты (записи) - документы различных типов, имеющие соответствующие процедуры-методы. Атрибуты разных объектов хранились в разных таблицах, связанной с основной 1-1. Имелась структура, хранящая метаданные - инфу, о том, где и храняться атрибуты объекта в зависимости от типа. Пользователь системы мог завести объект нового типа, в этом случае наши служебные процедуры добавляли в БД соответствующие таблицы и метаданные и на основании метаданных, генерировали основные пользовательские процедуры для работы с новым типом объекта.
Для данной системы это оказалось вполне работоспособное решение, т.к. клиент преимущественно работал пообъектно (вставлял, удалял, редактировал). При данном подходе так же было достаточно просто внести изменения в логику поведения того или иного типа объектов, что было немаловажно т.к. во-первых обекты взаимодействовали м/у собой по достаточно сложным правилам, а во-вторых эти правила могли меняться.

ЗЫ но нада отдавать себе отчет, что данную модель можно наложить далеко не на каждую задачу...
12 мар 07, 17:40    [3888722]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
WiRuc
Ну, это совсем другое дело. Разнесение сущностей на 1-1 в принципе практикуется (скажем, контрагенты -> физ.лица, юр. лица).


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

Вот именно единственная родительская сущность меня и смущает. Ну не укладывается у меня в голове, как такой подход может показывать сносную производительность на системе, в которой за раз вставляется несколько тысяч документов. И производятся модификации, затрагивающие десятки тысяч документов за раз.
pkarklin, спасибо, дали пищу для размышлений. Было бы конечно интересно самому в живую поэксплуатировать такую систему.
12 мар 07, 17:49    [3888764]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
aag
Member

Откуда: Москва
Сообщений: 1955
WiRuc
Вот именно единственная родительская сущность меня и смущает. Ну не укладывается у меня в голове, как такой подход может показывать сносную производительность на системе, в которой за раз вставляется несколько тысяч документов

На самом деле, зря смущает. Сама по себе одна таблица может и не быть затыком. У нас есть несколько таблиц - не имеющие отношения к ООП, нечто связанное с логированием, в которых за день набирается до 200 тыс. записей. И ничего, шуршат. Чтобы было понятней, для выборок эти таблицы также используется довольно активно (скажем, сотни раз в день).
А вот навороты, призванные подтянуть обьектный подход для красоты меня в данном случае смущают гораздо больше.



Nobody faults but mine... (LZ)
12 мар 07, 18:42    [3889053]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

Откуда: Москва
Сообщений: 5503
Блог
aag
И ничего, шуршат. Чтобы было понятней, для выборок эти таблицы также используется довольно активно (скажем, сотни раз в день).
ИМХО, сотни в час... ;)

aag
А вот навороты, призванные подтянуть обьектный подход для красоты меня в данном случае смущают гораздо больше.
Если навороты ради наворотов - да. А вот не забывать про объекты при проектировании - это правильно. Очень часто хорошо положенная на реляционную базу объектная структура - оптимальное решение. Конечно, это решение не должно начинаеться с таблицы Object, если только нет нужды ССЫЛАТЬСЯ на сущности класса ТАКОГО уровня наследования. Обычно достаточно базовых классов типа "Контрагенты", "Документы", "Объекты учета" и т.д.
12 мар 07, 18:56    [3889115]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
aag
А некие системы, ориентированные на гибкость, на хранение и доступ данных произвольного вида - то, о чем пишет pkarklin - разумеется, да, существуют почти в каждой крупной ИС. Сделать такую штуку с удачным балансом производительности/гибкости трудно, но можно - но к инкапсуляции, полиформизму и наследованию она будеть иметь очень далекое отношение.

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

Какое отношение это имеет к настоящему наследованию (в терминах именно ООП), а тем более к инкапсуляции и полиморфизму - я вообще не понимаю.

Оракл в свое время громко вопил, что они как раз ежа с ужом и того... Почти как с ланью этой несчастной. То есть реализовали возможность иметь сложные типы данных. Описываем тип Object, в нем такие-то поля, потом создаем таблицу, а в ней можно завести поле типа Object. Ну и перегрузку операций для таких типов вроде сделали, если я ничего не путаю. Тоже про ООП все гремели...
12 мар 07, 18:58    [3889124]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
ChA
Member

Откуда: Москва
Сообщений: 11319
GreenSunrise
для данного топика ООП означает иметь базовую сущность, а наследники - это всего лишь таблицы, которые свои "унаследованные" члены хранят в общей таблице.

Какое отношение это имеет к настоящему наследованию (в терминах именно ООП), а тем более к инкапсуляции и полиморфизму - я вообще не понимаю.
IMHO, дело в абстракции, как таковой. При стандартном реляционном подходе каждая таблица являет собой некую сущность предметной области, а во всех упоминаниях данного топика подразумеваются абстрактные объекты, конкретизация которых обычно происходит на уровне приложения, а не сервера. Именно поэтому довольно часто такие модели данных упоминаются в связи с ORM - object-relational mapping. В них главный плюс только один, на мой взгляд, отсутствие необходимости изменения схемы БД при изменениях структуры и поведения сущностей предметной области postfactum. Если таковые и появляются, то можно сказать - автоматически, так как генерируются на основе какой-либо метаинформации.
12 мар 07, 20:11    [3889312]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
JET?
Guest
Shurgenz
Как его отфутболить поумнее?

Можно свои 3 копейки?

Вопрос: Почему ООП на Яве - весчь, а на VB - сплошной геморр?
Ответ: Потому, что, если средства разработки не поддерживают ООП, то эту поддержку придется писать самому.


Вопрос: Писать или не писать? =>

1. Зачем это надо?
2. Насколько это сложно? Оправдает ли себя вложенный труд?

Ответы (ИМХО):

1. Зависит от задачи.
2. Если написать поддержку ООП в реляционной СУБД не очень сложно (под силу двум
мужикам), то почему Микрософт этого не сделал, а Оракул сделал, прямо скажем, кривовато?
12 мар 07, 21:27    [3889417]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
DeColo®es
Конечно, это решение не должно начинаеться с таблицы Object, если только нет нужды ССЫЛАТЬСЯ на сущности класса ТАКОГО уровня наследования.


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


Коллеги. Наличие единой базовой сущности не является самоцелью. Рассмотрим некоторые классические потребности любой информационной системы:

Идентификация сущности в системе. На предмет сурогатный\естественный ключ уже не мало копий сломано, однако, в большинстве случаев выбор склонятеся в сторону того или иного сурогатного ключа. Теперь сделаем шаг дальше... А почему бы, если каждая сущность имеет сурогатный ключ не иметь единое глобальное для системы протсранство идентификаторов сущностей? Чем это может помочь в дальнейшем проектировании:

1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой
2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;
3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;
4. Общий механизм поддержки расширяемых атрибутов;
5. Единую систему журналирования событий;

Обратите внимание, что все Выше описанное сделано на уровне ядра (читай на уровне общей родительской таблицы). Таким образом вне зависимости от дальнейшего развития системы (увеличения числа прикладных объектов) весь этот механизм продолжает успешно работать. И изменение это механизма ядра моментально скажеться на поведении всех прикладных объектов в системе.

А теперь представьте себе реализацию такого меанизма при класическом подходе, когда каждая сущность представлена отдельной таблицей, не имеющей "общего предка". Реализацию всех пунктов, описанных выше, придеться повторять для каждой отдельной сущности. Согласитесь, не слишком благодарный труд. Лучше это время потратить на проектирование и реализацию поведенческих характеристик прикладных объектов в системе.

Все описанное выше, конечно, не является ООП в классическом его понимании, но что-то очень похожее по своей идеологии и поведению. IMHO.

Обратите внимание, что при таком подходе все равно нет отхода от реляционной струтктуры.
13 мар 07, 08:42    [3890087]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin

1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой
2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;
3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;
4. Общий механизм поддержки расширяемых атрибутов;
5. Единую систему журналирования событий;

Один в один из ссылки по ВЕРО, которую вы давали. Случаем, не имеете отношение к ее разработке?
По пунктам:
1) Решается введением таблиц(ы) для поддержки метаинформации.
2) Далеко не все сущности нуждаются в схеме состояний. Получается избыточность, что не есть хорошо.
3,5) Решается генерацией кода на основе шаблонов. Ручками код не пишут. Опять таки, в последствии легко вносятся изменения.
4) Опять таки не вижу проблем это решить введением метаинформации, описывающей сущности, и таблиц(ы) для поддержки дополнительных аттрибутов в разрезе сущностей.
А теперь посмотрим на журнализацию. Вы писали, что у вас максимальная глубина иерархии 7 уровней. Это значит, что при добавлении новой записи у вас будет фактически вставлено 14 записей (7 + 7 на журнализацию) против 2 в стандартной реализации. Разница в 7 раз - это довольно много, вы не находите? Особенно, учитывая, что даже обычная журнализация просаживает производительность системы на 20-30%. Но, в случае необходимости, журнализацию можно отключить, а здесь уже ничего не отключишь:)
Еще вопрос. Как в такой схеме обеспечивается работа с множеством записей? Если можно, конкретный пример реализации. Например, нам нужно поменять статус у всех накладных за сегодняшний день.
13 мар 07, 10:39    [3890591]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить