ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / ООП на сервере
139 сообщений из 139, показаны все 6 страниц
  все  
ООП на сервере
    #34384584
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
Пришел к нам на работу ДБ девелопер, мне типа в помощь (зачем - непойму, вродеб и так справляюсь)

И начал толкать ООП подход ко всему, что в БД храниться...

типа

авторПонятие класса в базе данных: каждый класс соответствует таблице, запись таблицы является экземпляром класса. Каждый экземпляр класса должен однозначно идентифицироваться в таблице, поэтому в каждой таблице обязательно должно присутствовать поле – ключ объекта. В качестве ключа объекта очень желательно использовать целочисленное значение (суррогатный ключ). При этом данный ключ должен быть уникальным в пределах всей базы, а это значит, что для любого класса БД должен быть один общий предок, назовём его Object, а его ключевое целочисленное поле OID (Object IDentifier). Любой объект БД имеет текстовое наименование, по которому его идентифицирует пользователь в клиентском приложении, поле Name, а также каждый объект должен иметь поле, в котором хранится ссылка на его класс. В результате получаем:

Код: plaintext
1.
2.
3.
4.
5.
6.
Create table Object
(
  OID   int identity( 1 ,  1 ),
  Name  nvarchar( 256 ),
  Class varchar( 32 ) not null,
  Primary key clustered ( OID )
)

авторДля наследника с дополнительными атрибутами необходимо создавать дополнительную таблицу с названием, соответствующим названию класса и обязательным наличием поля OID int not null primary key. По этому полю данные класса наследника соединяются с классом родителем один-к-одному. Создадим класс наследник Subject c дополнительными атрибутами Address (адрес субъекта) и OwnerOID (ссылка на вышестоящего субъекта-владельца, например для склада это компания). Любую ссылку на объект нужно именовать в нотификации <Атрибут>OID, дабы отличить ссылки на объект от обычных числовых или других идентификаторов.
Код: plaintext
1.
2.
3.
4.
5.
6.
Create table Subject
(
  OID      int not null,
  Address  nvarchar( 2000 ),
  OwnerOID int, 
  Primary key clustered ( OID )
)
авторКласс WorkGroup имеет атрибут-коллекцию, состоящую из списка пользователей, входящих в группу. В базе это реализуется в виде такой таблицы:
Код: plaintext
1.
2.
3.
4.
5.
Create table WorkGroup_Users
(
  OID     int not null,  -- ссылка на WorkGroup (this в C#)
  UserOID int not null,  -- ссылка на пользователя
  Primary key clustered ( OID, UserOID )
)

Код: plaintext
1.
2.
3.
4.
Create procedure Object_Open
  @OID int
As
  Select * from Object where OID = @OID
Go

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Create procedure Subject_Open
  @OID int
As
  Select s.*,
         OwnerName = o.Name,
         OwnerClass = o.Class
    From Subject s
           Left join
         Object o
           On o.OID = s.OwnerOID
    Where s.OID = @OID
go

авторПри таком подходе метод Open класса Subject на сервере приложений перекрывает виртуальный метод класс предка и в начале кода вызывает родительский метод. Таким образом именно сервер приложений обеспечивает совокупный вызов всех методов Open от базового класса до текущего.

автор2. Наследование методов реализовано в базе данных

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Create procedure Subject_Open
  @OID int
As
  Select o.*,
         s.Address,
         s.OwnerOID,
         OwnerName = so.Name,
         OwnerClass = so.Class
    From Object o
           Left join
         Subject s
           On s.OID = o.OID
           Left join
         Object so
           On so.OID = s.OwnerOID
    Where o.OID = @OID
Go

Или

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Create procedure Subject_Create
  @OID      int out,
  @Name     nvarchar( 256 ),
  @Class    varchar( 32 )
  @Address  nvarchar( 2000 ),
  @OwnerOID int
As
  Exec Object_Create @OID out, @Name, @Class

  Insert Subject(OID, Address, OwnerOID)
    Select @OID, @Address, @OwnerOID
go
И т.д и т.п.

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

Грит, при подходе с классами можно реализовать логику бизнес процесса... млин, в этот бред даже вникать неохота.
...
Рейтинг: 0 / 0
12.03.2007, 14:56
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384601
Фотография Knyazev Alexey
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Knyazev Alexey
Участник
Интересный подход
...
Рейтинг: 0 / 0
12.03.2007, 15:00
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384602
Фотография Max-xaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Max-xaM
Участник
Напоминает мне одного человека.
Как его зовут? Из какой фирмы пришел?
...
Рейтинг: 0 / 0
12.03.2007, 15:01
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384612
Фотография Ray D
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ray D
Участник
ну подход как похдод, видел и хуже :) единственное, что не надо его преподносить как единственно верный и пихать везде, где только можно.
...
Рейтинг: 0 / 0
12.03.2007, 15:04
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384620
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
Max-xaMНапоминает мне одного человека.
Как его зовут? Из какой фирмы пришел?

Я тебе по Мылу отвечу, в форуме не буду...
...
Рейтинг: 0 / 0
12.03.2007, 15:06
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384625
Фотография Max-xaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Max-xaM
Участник
Shurgenz Max-xaMНапоминает мне одного человека.
Как его зовут? Из какой фирмы пришел?

Я тебе по Мылу отвечу, в форуме не буду...
max-xam3k@mail.ru
...
Рейтинг: 0 / 0
12.03.2007, 15:06
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384626
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
Ray Dну подход как похдод, видел и хуже :) единственное, что не надо его преподносить как единственно верный и пихать везде, где только можно.

вот вот... я только не пойму, как он собирается его продвигать в нашем проекте... а так может быть подход как подход
...
Рейтинг: 0 / 0
12.03.2007, 15:07
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384650
Фотография Max-xaM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Max-xaM
Участник
Просто есть программисты-теоретики, а есть программисты-практики.
Пусть попробует прикинуть сколько времени ему понадобится, чтобы имеющуюся БД переделать под новый механизм. А также пусть оценит скорость ее работы в случае, когда БД достигнет 20-30 гигов. Каждый раз обращаться к списку объектов-субъектов.... жуть!
На прошой работе была не очень большая БД, которую один ботаник захотел переделать под аналогичную структуру. Это у него заняло пол-года, но ничего не сделал. Куча затыков, которые он не смог преодолеть. Результат: крутится та же база, что и была, ботаник научился ее поддерживать.

Так что предложи ему сделать свою и посмотри когда он закончит или скажет что-то типа "У вас гранаты не той системы, ничего не получится". :-)
...
Рейтинг: 0 / 0
12.03.2007, 15:12
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384657
Фотография ziktuw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ziktuw
Участник
Гибкость обратно пропорциональна производительности. Поэтому к ООП в базах данных нужно подходить очень вдумчиво.

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


----------------------------------------------------------------
Да полно-те Вам. Не стоит благодарности.
...
Рейтинг: 0 / 0
12.03.2007, 15:17
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384667
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
я ему уже задаю вопросики... насколько я понимаю, при ООП при каждом инсерте инсертить придется на самом деле в 2+ таблиц (типа в таблицу связи с родителями тоже)

Удалять и селектить то же самое... уже наводит тоску
...
Рейтинг: 0 / 0
12.03.2007, 15:18
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384670
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
ООП плохо ложиться на реляционную БД. В теории все выглядит красиво, а на практике просто ужас: низкая производительность, проблемы с массовой обработкой записей и т.д. Вот у вас всего 2 уровень наследования, а уже 2 вставки на сущность Subject. Что будет, если иерархия будет n-уровневой?
Вывод: хорошо для общего развития и небольших БД, не оперирующими миллионами записей.
Если есть желание заюзать именно ООП, то нужно смотреть в сторону ОО СУБД.
...
Рейтинг: 0 / 0
12.03.2007, 15:19
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384672
MsDatabaseru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MsDatabaseru
Участник
скажи ему так
1 что это замечательный подход для разработки принципиально новых проектов в которых требуется унификация для разработчика но не важны фактические показатели быстродействию системы и удобства для дизайна на уровне tsql
2 что на работе подчиненному надо выполнять поставленные задачи, а выбирать концепцию - удел руководителей проектов, обладающих соответствующей квалификацией, хотябы всилу того что всю ответсвенность за реализацию несет именно руководитель и в случае неудач виновать будет он.
3 В случае если нельзя но очень хочется, свои научные или эстетические изыски он может реализовать дома, в свободное от работы время (по другому говоря пусть тренируется на.. кошках)
...
Рейтинг: 0 / 0
12.03.2007, 15:20
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384675
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ShurgenzУдалять и селектить то же самое... уже наводит тоску

Ну, не все уж так тоскливо. Процедура вставки объекта будет содержать вызов процедуры вставки родительского объекта и INSERT в таблицу самого объекта.

На счет подхода - применим, но с умом. И не обязательно в контексте:

авторПри таком подходе метод Open класса Subject на сервере приложений перекрывает виртуальный метод класс предка и в начале кода вызывает родительский метод. Таким образом именно сервер приложений обеспечивает совокупный вызов всех методов Open от базового класса до текущего.
...
Рейтинг: 0 / 0
12.03.2007, 15:21
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384678
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
DibrovГибкость обратно пропорциональна производительности.
Золотые слова:) Еще со времен ассемблера пошло. Я бы еще добавил " и удобство разработки".
...
Рейтинг: 0 / 0
12.03.2007, 15:22
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384687
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucООП плохо ложиться на реляционную БД.

Ну, скажем так, я бы не стал называть приведенный подход "реализацией ООП в реляционной СУБД". IMHO, это некое развитие модели, создать одну таблицу документов на все возможные типы документов с кучей полей, допускающих NULL, или прикинуть, и создать некую модель (м.б. и напоминающей наследование) из нескольких таблиц с отношением 1-к-1 и полями NOT NULL.
...
Рейтинг: 0 / 0
12.03.2007, 15:25
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384700
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklinНу, не все уж так тоскливо. Процедура вставки объекта будет содержать вызов процедуры вставки родительского объекта и INSERT в таблицу самого объекта.

Куда уж тоскливей:) Как минимум 1 лишняя вставка. А максимум не ограничен. И табличка Object родительская, на нее идут все вставки. Может такой затык при массированных вставках случиться:) А уж блокировки... А деадлоки, из-за появления "вертикальной" иерархии...
...
Рейтинг: 0 / 0
12.03.2007, 15:29
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384704
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
pkarklin ShurgenzУдалять и селектить то же самое... уже наводит тоску

Ну, не все уж так тоскливо. Процедура вставки объекта будет содержать вызов процедуры вставки родительского объекта и INSERT в таблицу самого объекта.

На счет подхода - применим, но с умом. И не обязательно в контексте:

авторПри таком подходе метод Open класса Subject на сервере приложений перекрывает виртуальный метод класс предка и в начале кода вызывает родительский метод. Таким образом именно сервер приложений обеспечивает совокупный вызов всех методов Open от базового класса до текущего.

Может быть для справочных таблиц, в которых не так уж много записей.. А когда таблицы раздуты и они совсем немаленькие... Ведь для каждого объекта, чтоб выбрать информацию, нужно читать иногда из всех его родителей тоже, да + еще WorkGroup_Users - которая осуществляет многие-ко-многим меж ними... и помножить на степень наследования.
...
Рейтинг: 0 / 0
12.03.2007, 15:30
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384713
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklin WiRucООП плохо ложиться на реляционную БД.

Ну, скажем так, я бы не стал называть приведенный подход "реализацией ООП в реляционной СУБД". IMHO, это некое развитие модели, создать одну таблицу документов на все возможные типы документов с кучей полей, допускающих NULL, или прикинуть, и создать некую модель (м.б. и напоминающей наследование) из нескольких таблиц с отношением 1-к-1 и полями NOT NULL.
По моему в Дейте как раз и описывалась подобная архитектура. Как раз в разделе объектно-ориентированного подхода.
...
Рейтинг: 0 / 0
12.03.2007, 15:34
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384726
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
WiRuc pkarklin WiRucООП плохо ложиться на реляционную БД.

Ну, скажем так, я бы не стал называть приведенный подход "реализацией ООП в реляционной СУБД". IMHO, это некое развитие модели, создать одну таблицу документов на все возможные типы документов с кучей полей, допускающих NULL, или прикинуть, и создать некую модель (м.б. и напоминающей наследование) из нескольких таблиц с отношением 1-к-1 и полями NOT NULL.
По моему в Дейте как раз и описывалась подобная архитектура. Как раз в разделе объектно-ориентированного подхода.

И.... ссылка есть?
...
Рейтинг: 0 / 0
12.03.2007, 15:37
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384737
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
Shurgenz WiRuc pkarklin WiRucООП плохо ложиться на реляционную БД.

Ну, скажем так, я бы не стал называть приведенный подход "реализацией ООП в реляционной СУБД". IMHO, это некое развитие модели, создать одну таблицу документов на все возможные типы документов с кучей полей, допускающих NULL, или прикинуть, и создать некую модель (м.б. и напоминающей наследование) из нескольких таблиц с отношением 1-к-1 и полями NOT NULL.
По моему в Дейте как раз и описывалась подобная архитектура. Как раз в разделе объектно-ориентированного подхода.

И.... ссылка есть?
У меня книга
...
Рейтинг: 0 / 0
12.03.2007, 15:39
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384758
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucКак минимум 1 лишняя вставка. А максимум не ограничен. И табличка Object родительская, на нее идут все вставки. Может такой затык при массированных вставках случиться:) А уж блокировки... А деадлоки, из-за появления "вертикальной" иерархии...

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

Затыки при массированной вставке могут быть и без использования такого подхода. Впрочем как и блокировки, так и дедлоки (тьфу, тьфу)...

ShurgenzМожет быть для справочных таблиц, в которых не так уж много записей.. А когда таблицы раздуты и они совсем немаленькие...

Нате:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT
  COUNT(*)
FROM
  dbo.Object

            
----------- 
 48238724 

( 1  row(s) affected)
...
Рейтинг: 0 / 0
12.03.2007, 15:46
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384760
Фотография tpg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tpg
Участник
ShurgenzКак его отфутболить поумнее? Лажа ведь какая-тоНу, например, пусть вспомнит историю возникновения ООП, хотябы утрировано: мол сидела программерская контора и ваяла софт на заказ.
Пока заказчиков было не много и заказы довольно сильно отличались друг от друга, всё шло гладко.
Но вот, повалили заказчики кучей и заказы были как братья близнецы похожи друг на друга, за исключением небольших отличий - кинулись плодить подпрограммы (а ничего ещё кроме процедурного программизма не придумали на то время) и поняли, что так у них под исходники никаких носителей не хватит, да и поддержка такого кода, мяхко говоря - грубо выражаясь...
Вот тут и взялись несколько энтузазистов за "облогараживание" процесса разработки...
Так, или примерно так, и появилось ООП... Красота...
Но, ИМХО, основная цель ООП как была, так и остается - снизить издержки на проектирование софта, но там, где ему не место (РСУБД как раз относится к тем местам, где оно слабо применимо).
Действительно, есть ОО СУБД, вот на них это самое какава. ;-)
Это как параллелизм: 9 женщин не смогут родить за 1 месяц ребенка, но вот за 9 вполне произвести 9.
...
Рейтинг: 0 / 0
12.03.2007, 15:47
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384791
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
ShurgenzРезать, к чортовой матери, не дожидаясь перитонита С такой схемой он вас похоронит. Наверняка практического опыта в реализации подобной подхода у него нет, и учиться он будет на вас, а это может дорого стоить.
...
Рейтинг: 0 / 0
12.03.2007, 15:54
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384810
Фотография tpg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tpg
Участник
ChA ShurgenzРезать, к чортовой матери, не дожидаясь перитонита С такой схемой он вас похоронит. Наверняка практического опыта в реализации подобной подхода у него нет, и учиться он будет на вас, а это может дорого стоить .+1
...
Рейтинг: 0 / 0
12.03.2007, 15:58
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384811
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklinЕще раз, я ни кого не пытаюсь убеждать, что это единмтвенно правильный подход.

Я понимаю. У нас конструктивный диалог
pkarklin
Затыки при массированной вставке могут быть и без использования такого подхода. Впрочем как и блокировки, так и дедлоки (тьфу, тьфу)...

Согласитесь, что в данном подходе затыки значительно усилены за счет того, что Object является бутылочным горлышком. Причем тормозить будет вся система в целом, а не скажем работа с накладными.

pkarklin
Нате:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
SELECT
  COUNT(*)
FROM
  dbo.Object

            
----------- 
 48238724 
( 1  row(s) affected)

У вас промышленная эксплуатация такой системы? Давайте тогда подробности...
...
Рейтинг: 0 / 0
12.03.2007, 15:58
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384822
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
ChA ShurgenzРезать, к чортовой матери, не дожидаясь перитонита С такой схемой он вас похоронит. Наверняка практического опыта в реализации подобной подхода у него нет, и учиться он будет на вас, а это может дорого стоить.

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

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

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

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

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

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

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

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

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

А автору действительно следует во-первых, объяснить, что прежде всего надо придерживаться принятого корпоративного стандарта. Во-вторых надо рассматривать применимость предлагаемой структуры к конкретной задаче. А в-третьих нужно прикинуть трудоемкость перехода на новую структуру данных.
...
Рейтинг: 0 / 0
12.03.2007, 16:05
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384829
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucСогласитесь, что в данном подходе затыки значительно усилены за счет того, что Object является бутылочным горлышком.

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

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

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

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

Что Вас конкретно интересует?
...
Рейтинг: 0 / 0
12.03.2007, 16:07
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384833
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Бывший казначей2 - реализация была чуть менее ортодоксальной - на уровне представлений и хранимок все-таки прослеживался скорее РСУБД-шный подход, что в сочетании с такой структурой таблиц действительно обеспечивало высокую гибкость.

Золотые слова. Именно такая реализация и используется.
...
Рейтинг: 0 / 0
12.03.2007, 16:09
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384860
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
Shurgenz
автормоя прежняя работа это ***

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

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

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

Все запросы очень простые были и работали на ура.где именно у нас это можно воплотитьНу, если сверху дали добро, пусть применяет, от Вас, в данном случае, похоже, ничего не зависит.
Теперь касательно речи автора. Что такое извращенные запросы в его терминологии ? У нас, например, при подобном подходе иногда такие запросы получаются, что мама не горюй. И именно в связи с оптимизацией. Я, конечно, не знаю, что там за миллионы с миллиардами, но похоже, что логика ранее была более чем простой, если судить по схеме. У нас например, бухучет живет с самой, что ни на есть извращенной логикой, которая только может придти "гениям", которые периодически ставят всю страну на уши своими новыми законами, правилами и прочей фигней. И, Боже, как это задолбало
...
Рейтинг: 0 / 0
12.03.2007, 16:17
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384867
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklinЧто Вас конкретно интересует?
Общее описание: что за система (предметная область), какая глубина иерархии, как реализованы массовые операции над сущностями, количество пользователей, количество транзакций в секунду, были ли проблемы с производительностью и как их решали.
Больше всего меня интересует Ваше мнение в сравнении с традиционным подходом. Вот скажем, реализовали бы такую систему в стандартном варианте, в чем бы мы выиграли, а в чем проиграли.
...
Рейтинг: 0 / 0
12.03.2007, 16:21
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384877
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
Cha:

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

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

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

Вот, пытаюсь выяснить теперь, как при ООП это все разрулить
...
Рейтинг: 0 / 0
12.03.2007, 16:26
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384883
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
Бывший казначей
1 - Иерархия классов там была двухуровневой (финансовые документы - пратежные поручения, реестры и т.п.)
2 - реализация была чуть менее ортодоксальной - на уровне представлений и хранимок все-таки прослеживался скорее РСУБД-шный подход, что в сочетании с такой структурой таблиц действительно обеспечивало высокую гибкость.

Ну, это совсем другое дело. Разнесение сущностей на 1-1 в принципе практикуется (скажем, контрагенты -> физ.лица, юр. лица).
Другое дело, если мы БД будем реализовывать как классы в .NET - object и погнали наращивать иерархию.
...
Рейтинг: 0 / 0
12.03.2007, 16:27
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384917
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
Например, как мне решить такую задачу: Есть 3-х уровневая иерарахия. Для итоговой сущности я хочу сделать выборку по 3 полям, по одному полю из каждого уровня иерархии. Каждое условие по отдельности имеет низкую селективность, а вместе они дают высокую селективность. Как мне реализовать выборку с достаточной производительностью? На обычной таблице это решается путем построения составного индекса.
...
Рейтинг: 0 / 0
12.03.2007, 16:40
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384932
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRuc pkarklinЧто Вас конкретно интересует?
Общее описание: что за система (предметная область), какая глубина иерархии, как реализованы массовые операции над сущностями, количество пользователей, количество транзакций в секунду, были ли проблемы с производительностью и как их решали.
Больше всего меня интересует Ваше мнение в сравнении с традиционным подходом. Вот скажем, реализовали бы такую систему в стандартном варианте, в чем бы мы выиграли, а в чем проиграли.

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

При реализации "стандартным" подходом сильно бы проиграли на сроках реализации решений, ибо огромная часть логики реализована в ядре системы. На производительности -такой подход врядли сильно сказался бы отрицательно, даже, IMHO, наоборот. Ибо "узких мест" - единицы, а они не разбросаны по все системе и их легче "отловить" и оптимизировать.
...
Рейтинг: 0 / 0
12.03.2007, 16:42
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384937
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucНапример, как мне решить такую задачу: Есть 3-х уровневая иерарахия. Для итоговой сущности я хочу сделать выборку по 3 полям, по одному полю из каждого уровня иерархии.

Любая сущность в системе (состоящая из от 1 до N таблиц) представлена представлением. (Прошу прощения за каламбур). Нет прямого доступа к таблицам. Индекс будет построен на представлении.
...
Рейтинг: 0 / 0
12.03.2007, 16:45
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384944
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucНу, это совсем другое дело. Разнесение сущностей на 1-1 в принципе практикуется (скажем, контрагенты -> физ.лица, юр. лица).

Ну, так и сделано, в принципе, только за одним исключением, что есть одна единственная "родительская" сущность.
...
Рейтинг: 0 / 0
12.03.2007, 16:47
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384979
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LR
Участник
Можно еще поискать обсуждения по теме на форуме "Разработка информационных систем", вот одно из таких(эпических):

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

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

ВЕРО - единый реестр объектов
...
Рейтинг: 0 / 0
12.03.2007, 16:56
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384983
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aag
Участник
Тема ООП в реляционных СУБД практически неисчерпаема. Каждый свежеиспеченный разработчик баз данных бросается создавать обьектную модель. Наиболее грамотные из них через некоторое время, поломав себе зубы и набив шишки (это в лучшем случае), выстраивают нечто вроде
автор... реализация была чуть менее ортодоксальной - на уровне представлений и хранимок все-таки прослеживался скорее РСУБД-шный подход, что в сочетании с такой структурой таблиц действительно обеспечивало высокую гибкость.

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

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

Nobody faults but mine... (LZ)
...
Рейтинг: 0 / 0
12.03.2007, 16:57
| Ответить | Цитировать | Написать  
ООП на сервере
    #34384997
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
LRВЕРО - единый реестр объектов

Ну, тогда уж так: Ставка на ВЕРО ;)
...
Рейтинг: 0 / 0
12.03.2007, 17:00
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385065
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LR
Участник
pkarklin LRВЕРО - единый реестр объектов

Ну, тогда уж так: Ставка на ВЕРО ;)
О, спасибо, этот вопрос интересует уже давно, уже читаю :)
...
Рейтинг: 0 / 0
12.03.2007, 17:22
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385129
Вдрызг
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вдрызг
Участник
Работал с БД, структура которой отчасти напоминала обсуждаемую схему. Система документооборота. Сходство было в том, что тоже были объекты (записи) - документы различных типов, имеющие соответствующие процедуры-методы. Атрибуты разных объектов хранились в разных таблицах, связанной с основной 1-1. Имелась структура, хранящая метаданные - инфу, о том, где и храняться атрибуты объекта в зависимости от типа. Пользователь системы мог завести объект нового типа, в этом случае наши служебные процедуры добавляли в БД соответствующие таблицы и метаданные и на основании метаданных, генерировали основные пользовательские процедуры для работы с новым типом объекта.
Для данной системы это оказалось вполне работоспособное решение, т.к. клиент преимущественно работал пообъектно (вставлял, удалял, редактировал). При данном подходе так же было достаточно просто внести изменения в логику поведения того или иного типа объектов, что было немаловажно т.к. во-первых обекты взаимодействовали м/у собой по достаточно сложным правилам, а во-вторых эти правила могли меняться.

ЗЫ но нада отдавать себе отчет, что данную модель можно наложить далеко не на каждую задачу...
...
Рейтинг: 0 / 0
12.03.2007, 17:40
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385153
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklin WiRucНу, это совсем другое дело. Разнесение сущностей на 1-1 в принципе практикуется (скажем, контрагенты -> физ.лица, юр. лица).

Ну, так и сделано, в принципе, только за одним исключением, что есть одна единственная "родительская" сущность.
Вот именно единственная родительская сущность меня и смущает. Ну не укладывается у меня в голове, как такой подход может показывать сносную производительность на системе, в которой за раз вставляется несколько тысяч документов. И производятся модификации, затрагивающие десятки тысяч документов за раз.
pkarklin, спасибо, дали пищу для размышлений. Было бы конечно интересно самому в живую поэксплуатировать такую систему.
...
Рейтинг: 0 / 0
12.03.2007, 17:49
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385307
aag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aag
Участник
WiRucВот именно единственная родительская сущность меня и смущает. Ну не укладывается у меня в голове, как такой подход может показывать сносную производительность на системе, в которой за раз вставляется несколько тысяч документов
На самом деле, зря смущает. Сама по себе одна таблица может и не быть затыком. У нас есть несколько таблиц - не имеющие отношения к ООП, нечто связанное с логированием, в которых за день набирается до 200 тыс. записей. И ничего, шуршат. Чтобы было понятней, для выборок эти таблицы также используется довольно активно (скажем, сотни раз в день).
А вот навороты, призванные подтянуть обьектный подход для красоты меня в данном случае смущают гораздо больше.



Nobody faults but mine... (LZ)
...
Рейтинг: 0 / 0
12.03.2007, 18:42
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385348
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
aagИ ничего, шуршат. Чтобы было понятней, для выборок эти таблицы также используется довольно активно (скажем, сотни раз в день).ИМХО, сотни в час... ;)

aagА вот навороты, призванные подтянуть обьектный подход для красоты меня в данном случае смущают гораздо больше.Если навороты ради наворотов - да. А вот не забывать про объекты при проектировании - это правильно. Очень часто хорошо положенная на реляционную базу объектная структура - оптимальное решение. Конечно, это решение не должно начинаеться с таблицы Object, если только нет нужды ССЫЛАТЬСЯ на сущности класса ТАКОГО уровня наследования. Обычно достаточно базовых классов типа "Контрагенты", "Документы", "Объекты учета" и т.д.
...
Рейтинг: 0 / 0
12.03.2007, 18:56
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385354
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
aagА некие системы, ориентированные на гибкость, на хранение и доступ данных произвольного вида - то, о чем пишет pkarklin - разумеется, да, существуют почти в каждой крупной ИС. Сделать такую штуку с удачным балансом производительности/гибкости трудно, но можно - но к инкапсуляции, полиформизму и наследованию она будеть иметь очень далекое отношение.
Вот и меня в данном обсуждении смущает то, что для данного топика ООП означает иметь базовую сущность, а наследники - это всего лишь таблицы, которые свои "унаследованные" члены хранят в общей таблице.

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

Оракл в свое время громко вопил, что они как раз ежа с ужом и того... Почти как с ланью этой несчастной. То есть реализовали возможность иметь сложные типы данных. Описываем тип Object, в нем такие-то поля, потом создаем таблицу, а в ней можно завести поле типа Object. Ну и перегрузку операций для таких типов вроде сделали, если я ничего не путаю. Тоже про ООП все гремели...
...
Рейтинг: 0 / 0
12.03.2007, 18:58
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385498
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
GreenSunriseдля данного топика ООП означает иметь базовую сущность, а наследники - это всего лишь таблицы, которые свои "унаследованные" члены хранят в общей таблице.

Какое отношение это имеет к настоящему наследованию (в терминах именно ООП), а тем более к инкапсуляции и полиморфизму - я вообще не понимаю.IMHO, дело в абстракции, как таковой. При стандартном реляционном подходе каждая таблица являет собой некую сущность предметной области, а во всех упоминаниях данного топика подразумеваются абстрактные объекты, конкретизация которых обычно происходит на уровне приложения, а не сервера. Именно поэтому довольно часто такие модели данных упоминаются в связи с ORM - object-relational mapping. В них главный плюс только один, на мой взгляд, отсутствие необходимости изменения схемы БД при изменениях структуры и поведения сущностей предметной области postfactum. Если таковые и появляются, то можно сказать - автоматически, так как генерируются на основе какой-либо метаинформации.
...
Рейтинг: 0 / 0
12.03.2007, 20:11
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385573
JET?
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JET?
Гость
ShurgenzКак его отфутболить поумнее?
Можно свои 3 копейки?

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


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

Ответы (ИМХО):
Код: plaintext
1.
2.
     1. Зависит от задачи.
     2. Если написать поддержку ООП в реляционной СУБД не очень сложно (под силу двум
     мужикам), то почему Микрософт этого не сделал, а Оракул сделал, прямо скажем, кривовато?
...
Рейтинг: 0 / 0
12.03.2007, 21:27
| Ответить | Цитировать | Написать  
ООП на сервере
    #34385940
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
DeColo®esКонечно, это решение не должно начинаеться с таблицы Object, если только нет нужды ССЫЛАТЬСЯ на сущности класса ТАКОГО уровня наследования.

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

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

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

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

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

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

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

Обратите внимание, что при таком подходе все равно нет отхода от реляционной струтктуры.
...
Рейтинг: 0 / 0
13.03.2007, 08:42
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386266
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklin
1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой
2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;
3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;
4. Общий механизм поддержки расширяемых атрибутов;
5. Единую систему журналирования событий;

Один в один из ссылки по ВЕРО, которую вы давали. Случаем, не имеете отношение к ее разработке?
По пунктам:
1) Решается введением таблиц(ы) для поддержки метаинформации.
2) Далеко не все сущности нуждаются в схеме состояний. Получается избыточность, что не есть хорошо.
3,5) Решается генерацией кода на основе шаблонов. Ручками код не пишут. Опять таки, в последствии легко вносятся изменения.
4) Опять таки не вижу проблем это решить введением метаинформации, описывающей сущности, и таблиц(ы) для поддержки дополнительных аттрибутов в разрезе сущностей.
А теперь посмотрим на журнализацию. Вы писали, что у вас максимальная глубина иерархии 7 уровней. Это значит, что при добавлении новой записи у вас будет фактически вставлено 14 записей (7 + 7 на журнализацию) против 2 в стандартной реализации. Разница в 7 раз - это довольно много, вы не находите? Особенно, учитывая, что даже обычная журнализация просаживает производительность системы на 20-30%. Но, в случае необходимости, журнализацию можно отключить, а здесь уже ничего не отключишь:)
Еще вопрос. Как в такой схеме обеспечивается работа с множеством записей? Если можно, конкретный пример реализации. Например, нам нужно поменять статус у всех накладных за сегодняшний день.
...
Рейтинг: 0 / 0
13.03.2007, 10:39
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386426
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
pkarklin1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой
А зачем оно нам надо? :) Для глобальных уникальных вполне подходит GUID. Ставить этот довод на первое место - не стоит, мягко говоря.

pkarklin2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;Не в одних только состояниях щассте. :( Да и статусы как правило очень специфичны для разных сущностей либо их будет такое количество, что работать будет просто неудобно.

pkarklin3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;В нашей системе этот универсальный механизм прекрасно существует без уникальных идентификаторов. :)

pkarklin4. Общий механизм поддержки расширяемых атрибутов; EAV. :) У нас она только в одной базе она присутствует в нескольких СПЕЦИФИЧНЫХ для каждой сущности реализациях. Но если бы все загонялось в самую универсальную - тормоза были бы те еще.

pkarklin5. Единую систему журналирования событий;И что она журналировать будет? Изменение некоего абстрактного общего для всех сущностей статуса? Но этого маловато.
Или расширенных атрибутов? Если атрибут объекта является "справочным", а не "бизнес" (вряд нормальные люди ли будут загонять бизнес-атрибуты с интенсивной обработкой в EAV) - журналировать его может и нужно, но журналирование специфичных, хранящихся в отдельных таблицах атрибутов - тем более. То есть вместо одной процедуры журналирования будет 2.

На самом деле, универсальные механизмы в п2-4 - действительно нужны. Но для них совсем необязательно для всех объектов заводить общего предка. Хотя его существование в общем-то ничем не мешает, но может стать бутылочным горлышком.
...
Рейтинг: 0 / 0
13.03.2007, 11:17
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386530
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
2 DeColo®es

Целью моего поста не являлась (и не будет являтся) агитация всех и вся за использование такого механизма. Я изложил свое видение вопроса и его плюсы.

DeColo®esА зачем оно нам надо? :) Для глобальных уникальных вполне подходит GUID. Ставить этот довод на первое место - не стоит, мягко говоря.

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

DeColo®esНе в одних только состояниях щассте. :( Да и статусы как правило очень специфичны для разных сущностей либо их будет такое количество, что работать будет просто неудобно.

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

DeColo®esВ нашей системе этот универсальный механизм прекрасно существует без уникальных идентификаторов. :)

Хм... Готов с интересом расмотреть Ваш вариант решения (с не связанными таблицами) следующей задачи. Пусть появлятся какая либо дополнительная сущность. Какое кол-во объектов бд, кроме таблицы самой сущности Вам необходимо будет создать для реализации RLS? И самое главной, как потом "корректно" встроить эти объекты в систему глобального поиска (просмотра, реадктирования, удаления) объекта в системе с учетом RLS?

DeColo®esУ нас она только в одной базе она присутствует в нескольких СПЕЦИФИЧНЫХ для каждой сущности реализациях. Но если бы все загонялось в самую универсальную - тормоза были бы те еще.

Можно уточнить - о каких тормазах и в каком месте Вы говорите, учитывая что расширенная атрибутика работает на базовом уровне системы?

DeColo®esИ что она журналировать будет? Изменение некоего абстрактного общего для всех сущностей статуса? Но этого маловато.

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

DeColo®esНа самом деле, универсальные механизмы в п2-4 - действительно нужны. Но для них совсем необязательно для всех объектов заводить общего предка. Хотя его существование в общем-то ничем не мешает, но может стать бутылочным горлышком.

Могу еще раз только повторить - я не приподношу это решение, как серебряную пулю.
...
Рейтинг: 0 / 0
13.03.2007, 11:45
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386561
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
Я не говорю ничего ни за, ни против наличия базовой таблицы. У нас в свое время была такая идея - сделать базовую таблицу для сущностей, но от этого отказались - побоялись именно того самого бутылочного горлышка.

Мне не нравится только употребление термина ООП в данном контексте. От ООП там 5%.

Теперь по упомянутым пунктам
pkarklin1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой
Да. Это есть. Но это также может быть легко решено другими способами без базовой таблицы. Например, как WiRuc написал.

pkarklin2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;
А если у меня список состояний и матрица переходов разная для "предка" и "потомка"? Полноценного наследования с виртуальными функциями все равно нет, поэтому базовая таблица тут особо не поможет.

pkarklin3. Унифицированное управление правами доступа к объектам, включая реализацию RLS;
+1 с WiRuc.

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

pkarklin5. Единую систему журналирования событий;
И опять-таки полегче. Если вы журналируете только факт изменений и вас интересует только id журналируемой сущности, то базовой таблицы достаточно. А меня вот интересует изменение значений полей (это не для примера, это в реальной системе у нас так). И фига мне с вашей базовой таблицы? У меня же по-прежнему нет виртуальной функции LogMe, которая в базовом классе сделает одно, а в наследнике другое, да еще и позволит обратиться к методу предка. И опять же, у нас триггера журналирования делаются кодогенерацией, поэтому никаких затруднений с расширением таблицы мы не испытываем.

JET?Потому, что, если средства разработки не поддерживают ООП, то эту поддержку придется писать самому.
Именно! Именно так. Если нет нормальной поддержки в языке - все равно все ручками пишется. И то, что вы описали, мне не кажется ни более гибким, ни более удобным и легким в эксплуатации, ни более расширяемым.

P.S. Я ни в коем случае ничего не критикую и не против никаких предлагаемых тут решений. Я просто не вижу в них смысла и выигрыша.
...
Рейтинг: 0 / 0
13.03.2007, 11:51
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386633
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
2 GreenSunrise

Кое что описано суть выше, кое что уточню.

GreenSunriseА если у меня список состояний и матрица переходов разная для "предка" и "потомка"? Полноценного наследования с виртуальными функциями все равно нет, поэтому базовая таблица тут особо не поможет.

Именно так. Они разные. И есть "виртуальные функции" - хп ObjectSetState и ObjectExecStateTransit. Все. Далее механизм смены состояний работает вне зависимости от кол-ва прикладных объектов и их схем состояний.

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

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

Извиняюсь, допишу чуть позже... В офисе свет вырубают...
...
Рейтинг: 0 / 0
13.03.2007, 12:04
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386699
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LR
Участник
to pkarklin
Самым тонким и ответственным вопросом в этом деле мне представляется выбор полей/колонок для "стержневой" таблицы, т.е. какая информация должна содержаться в "стержневой" таблице, а какая выноситься в "хвостовые".
Одна крайность - хранить(регистрировать) в "стержневой" только ID и тип, вторая - напихать туда побольше "якобы общих" полей, вероятно, должна быть какая-то "золотая серединка" (зависящая от назначения системы)?

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

Возможно, как уже здесь отмечали, разумнее существование нескольких "стержневых" таблиц - по одной на каждое "крупное" пространство системы (по функционалу/назначению), например, зачем смешивать метаданные и данные в одной таблице(ведь это приводит к потере корректности ссылочной целостности) и т.п.?
...
Рейтинг: 0 / 0
13.03.2007, 12:15
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386801
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
pkarklin GreenSunriseА если у меня список состояний и матрица переходов разная для "предка" и "потомка"? Полноценного наследования с виртуальными функциями все равно нет, поэтому базовая таблица тут особо не поможет.

Именно так. Они разные. И есть "виртуальные функции" - хп ObjectSetState и ObjectExecStateTransit. Все. Далее механизм смены состояний работает вне зависимости от кол-ва прикладных объектов и их схем состояний.
Как именно это сделано, поясните, пожалуйста, я не понимаю.

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

Вот тут то вся и прелесть! Ничего менят мне не придеться. Объекту м.б. разрешено иметь определенную расширенную аттрибутику (настраивается с помощью мышечных усилий), причем можно задавать уникальные должны быть аттрибуты или нет. Например, объект договор может иметь только одно занчение типа "Оригинал договора" и несколько значений "Приложение к договору". И никакой кодогенерации.
Значит, я не понимаю понятия "расширенные атрибуты". Объясните, что это такое.
...
Рейтинг: 0 / 0
13.03.2007, 12:37
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386806
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
LR +1
Если это возможно, очень хотелось бы увидеть конкретный код некоторых ХП, например ObjectSetState. Можно на мыло.

авторВот тут то вся и прелесть! Ничего менят мне не придеться. Объекту м.б. разрешено иметь определенную расширенную аттрибутику (настраивается с помощью мышечных усилий), причем можно задавать уникальные должны быть аттрибуты или нет. Например, объект договор может иметь только одно занчение типа "Оригинал договора" и несколько значений "Приложение к договору". И никакой кодогенерации.
Я чет уже вообще ничего не понимаю Ну завели мы новый атрибут, но каким таким волшебным образом система узнает о НАЗНАЧЕНИИ этого атрибута и как его использовать в определенных ситуациях. Одно дело, если я на клиенте сразу автоматически могу его просматривать и изменять, тут никаких проблем и ООП для этого не нужен, а другое - его использование в серверной части (я не имею в виду журнализацию, RLS и прочие системные вещи).
...
Рейтинг: 0 / 0
13.03.2007, 12:39
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386831
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
2 GreenSunrise
Вы не одиноки. Я с каждым постом понимаю все меньше и меньше
...
Рейтинг: 0 / 0
13.03.2007, 12:43
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386876
DamirS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DamirS
Участник
2 All
М-да... замучаетесь вы с этой структурой.
Еще и методы-хранимки для обьектов писать...
Умный народ (Дейт, Кодд) про ДЕ нормализацию рассуждал: применять-не применять, какой выигрыш в производительности даёт...
А тут вот бесплатно получаем кучу join-ов при простой выборке 'обьекта'.

2Shurgenz
Что делать? Да отправить его на sql-ex.ru и разрешить внедрять свою систему только после прохождения 3-го оптимизационного этапа :)
...
Рейтинг: 0 / 0
13.03.2007, 12:53
| Ответить | Цитировать | Написать  
ООП на сервере
    #34386894
DamirS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DamirS
Участник
кстати, есть еще статейка Анатолия Тенцера про обьектную модель.
Много шума было вокруг этой модели.
Кому интересно - поиск по 'Тенцер' в инете.
...
Рейтинг: 0 / 0
13.03.2007, 12:57
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387021
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
DamirS 2 All
М-да... замучаетесь вы с этой структурой.
Еще и методы-хранимки для обьектов писать...
Умный народ (Дейт, Кодд) про ДЕ нормализацию рассуждал: применять-не применять, какой выигрыш в производительности даёт...
А тут вот бесплатно получаем кучу join-ов при простой выборке 'обьекта'.

2Shurgenz
Что делать? Да отправить его на sql-ex.ru и разрешить внедрять свою систему только после прохождения 3-го оптимизационного этапа :)

DamirS 2 All
М-да... замучаетесь вы с этой структурой.
Еще и методы-хранимки для обьектов писать...
Умный народ (Дейт, Кодд) про ДЕ нормализацию рассуждал: применять-не применять, какой выигрыш в производительности даёт...
А тут вот бесплатно получаем кучу join-ов при простой выборке 'обьекта'.

2Shurgenz
Что делать? Да отправить его на sql-ex.ru и разрешить внедрять свою систему только после прохождения 3-го оптимизационного этапа :)

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

Но на самом то деле, очень интересно про ObjectSetState и ObjectExecStateTransit услышать, и про атрибуты не очень понятно, но очень интересно
...
Рейтинг: 0 / 0
13.03.2007, 13:24
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387093
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Naf
Участник
ООП нормально, но только не в том виде, как предлагают: не нужно общую таблицу объектов, достаточно абстрактных классов, описание есть, а реализации нет, а вот в потомках (и то не 1-го уровня) можно и реализовать задекларированное
...
Рейтинг: 0 / 0
13.03.2007, 13:39
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387120
DamirS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DamirS
Участник
Shurgenz
Насколько я успел в этой всей схеме хоть что-то понять, там именно легкая, а может и не очень легкая степень денормализации...
По-моему, у него всё в тяжелой форме :)
Для снижения нагрузки на сервер специально применяют денормализацию с целью избавиться от join-ов при выборке данных.
Грубый пример: Есть справочник Код-->Название Dict(code int primary key, name varchar(30))
В некоей таблице Table1 есть внешний ключ Dict. Денормализация: в Table1 вместе с внешним ключём Dict помещают так же Dict.name. Именно из-за того, что join - операция затратная
А при такой вот обьектной модели мы грузим сервер join-ами, которых можно избежать просто нормально спроектировав базу.

Поправьте, если не прав.
...
Рейтинг: 0 / 0
13.03.2007, 13:45
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387165
DamirS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DamirS
Участник
Ага, вот и обсуждение нашёл - страшно подумать - 2002 год!
обсуждение статьи Тенцера
В этой же ветке есть ссылки на сами статьи.
...
Рейтинг: 0 / 0
13.03.2007, 13:55
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387191
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
NafООП нормально, но только не в том виде, как предлагают: не нужно общую таблицу объектов, достаточно абстрактных классов, описание есть, а реализации нет, а вот в потомках (и то не 1-го уровня) можно и реализовать задекларированное
Приведите пример, как это делается для баз. Не как это на плюсах пишут :-), а как это на T-SQL выглядит.
...
Рейтинг: 0 / 0
13.03.2007, 14:03
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387203
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
pkarklin DeColo®esА зачем оно нам надо? :) Для глобальных уникальных вполне подходит GUID. Ставить этот довод на первое место - не стоит, мягко говоря.

Например, для того, чтобы было возможно найти и открыть любой объект в системе по его ID. Если у Вас гуиды (или любые идентификаторы) будут разбросаны по не связанным таблицам, то Вам, в случаи добавления новой сущности придеться изменять часть кода, ответственного за ее поиск в системе. В случаи с единым родителем в этом нет необходимости.Э... А зачем мне искать объект, класс которого мне заранее не известен или непринципиален для процедуры поиска?

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

То есть для каждого вида поиска мне нужно в любом случае писать уникальную процедуру, как на клиенте, так и на сервере. (Ну не хранить же данные счетов и клиентов в EAV, нужно же еще и поиск по значениям НЕКОТОРЫХ СПЕЦИФИЧНЫХ аттрибутов со специально заточенными индексами делать). Единственное, что может быть универсально - окошко на клиенте, показывающее список.

Кроме того, количество уникальных классов сущностей не так уж и велико и, тем более, их список не так часто пополняется. И работа по созданию новых процедур - тоже несложная - от различных методов кодогенерации до банального copy/paste и проблем вроде не вызывает ни у кого. Гораздо больше сил отнимают работы по оптимизации работы системы, которая сделана на универсальных механизмах и просто не справляется с хранением и обработкой данных в них. Например, попытаться ускорить импорт больших списков в условиях, когда просто несуществует "API" для создания множества объектов одной командой.

А универсальные механизмы для группировок, RLS и прочего прекрасно существуют и без базовой таблицы. Просто в каждом механизме прописывается кроме прочего еще и "класс" объектов, данных которых хранит этот механизм. А если идентификатор объектов - уникальный, то и класс прописывать не всегда обязательно.
...
Рейтинг: 0 / 0
13.03.2007, 14:05
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387205
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
DamirS Shurgenz
Насколько я успел в этой всей схеме хоть что-то понять, там именно легкая, а может и не очень легкая степень денормализации...
По-моему, у него всё в тяжелой форме :)
Для снижения нагрузки на сервер специально применяют денормализацию с целью избавиться от join-ов при выборке данных.
Грубый пример: Есть справочник Код-->Название Dict(code int primary key, name varchar(30))
В некоей таблице Table1 есть внешний ключ Dict. Денормализация: в Table1 вместе с внешним ключём Dict помещают так же Dict.name. Именно из-за того, что join - операция затратная
А при такой вот обьектной модели мы грузим сервер join-ами, которых можно избежать просто нормально спроектировав базу.

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

Джойнов там ровно столько, какой по счету это потомок + пара вспомогательных, опционально, для атрибутов и иерархий. А потомка глубже 4-го уровня придумать в реальной жизни трудновато (мне по крайней мере). Скажем, сущности user & group не есть предок и потомок, а есть иерархия, вроде бы, вроде бы... или старею, или все это для меня, привыкшего к теории множеств на практике, непривычно, а потому не совсем понятно.
...
Рейтинг: 0 / 0
13.03.2007, 14:06
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387264
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
DamirSАга, вот и обсуждение нашёл - страшно подумать - 2002 год!
обсуждение статьи Тенцера
В этой же ветке есть ссылки на сами статьи.
Имхо, основной недостаток - о какой-либо бизнес-логике на стороне сервера можно забыть. По меньшей мере, я не представляю вменяемых сторед-прос или триггеров для работы с этим монстром. Триггеров особенно %-)

pkarklin, а вы такую систему имели в виду? У меня сложилось ощущение, что нет.
...
Рейтинг: 0 / 0
13.03.2007, 14:21
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387362
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Коллеги. Свет, наконец то, включили. Отвечу всем по-порядку...
...
Рейтинг: 0 / 0
13.03.2007, 14:45
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387406
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
GreenSunriseИ опять-таки полегче. Если вы журналируете только факт изменений и вас интересует только id журналируемой сущности, то базовой таблицы достаточно. А меня вот интересует изменение значений полей (это не для примера, это в реальной системе у нас так). И фига мне с вашей базовой таблицы? У меня же по-прежнему нет виртуальной функции LogMe, которая в базовом классе сделает одно, а в наследнике другое, да еще и позволит обратиться к методу предка. И опять же, у нас триггера журналирования делаются кодогенерацией, поэтому никаких затруднений с расширением таблицы мы не испытываем.

Ну, чтоб не быть голословным приведу просто скриншот логов одного из объектов (документ)
...
Рейтинг: 0 / 0
13.03.2007, 14:53
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387409
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
И лог контрагента. Все, что логгируется реализовано на базовом уровне.
...
Рейтинг: 0 / 0
13.03.2007, 14:54
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387453
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
LRОдна крайность - хранить(регистрировать) в "стержневой" только ID и тип, вторая - напихать туда побольше "якобы общих" полей, вероятно, должна быть какая-то "золотая серединка" (зависящая от назначения системы)?

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

LRнапример, зачем смешивать метаданные и данные в одной таблице(ведь это приводит к потере корректности ссылочной целостности) и т.п.?

В базе существует ссылочная целостность. Метаданные и данные в одной табоице не смешаны. Если посмотреть внимательно на структуру бд - классическая реляционная модель.
...
Рейтинг: 0 / 0
13.03.2007, 15:02
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387465
stomsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
stomsky
Участник
ShurgenzА потомка глубже 4-го уровня придумать в реальной жизни трудновато (мне по крайней мере).
Хотите подскажу? Справочник для Органа федерального казначейства:

Контрагент->Организация->Получатель_бюджетных_средств->Распрядитель_бюджетных_средств->Управление_федерального_казначейства

И это еще не предел! Хотя при такой иерархии может быть стоит подумать о другой структуре БД? Хотя с другой стороны если в поле "Получатель" платежного поручения может находиться как человек (физ.лицо), так и УФК по Волгоградской области! Т.е. наиболее разумным лично мне кажется отношение 1:М для таблиц "Контрагент" и "Платежные документы" (это я еще не расматриваю способы "размазать" по таблицам документы!).
...
Рейтинг: 0 / 0
13.03.2007, 15:07
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387471
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
ShurgenzНасколько я успел в этой всей схеме хоть что-то понять, там именно легкая, а может и не очень легкая степень денормализации...

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

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

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

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

Вы глубоко не правы.
...
Рейтинг: 0 / 0
13.03.2007, 15:08
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387475
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
Мне из картинок совершенно непонятно, что и как сделано с логгированием.
...
Рейтинг: 0 / 0
13.03.2007, 15:09
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387510
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Мдя. Видимо объясняльшик из меня плохой. Хотя вот так, пальцем трудно что-то показать. Надо бы со структурой бд, с кодом. GreenSunrise, WiRuc - процу отправил Вам на мыло. Но, думаю, что она только добавит вопросов.
...
Рейтинг: 0 / 0
13.03.2007, 15:17
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387516
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
pkarklinНичего подобного не происходит. Никаких DML - упаси господи.


При изменении состояния объекта никаких DML?
...
Рейтинг: 0 / 0
13.03.2007, 15:18
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387522
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
pkarklinМдя. Видимо объясняльшик из меня плохой. Хотя вот так, пальцем трудно что-то показать. Надо бы со структурой бд, с кодом. GreenSunrise, WiRuc - процу отправил Вам на мыло. Но, думаю, что она только добавит вопросов.
А мне можно? Временно открыл видимость... Потом закрою, а то спам всякий все больше стал сыпаться
...
Рейтинг: 0 / 0
13.03.2007, 15:20
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387527
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
Shurgenz pkarklinНичего подобного не происходит. Никаких DML - упаси господи.


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

Нет. Никакие действия в клиентском приложении не приводят к модификации структуры бд.
...
Рейтинг: 0 / 0
13.03.2007, 15:21
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387535
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
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.

При чем здесь структура? Извините
...
Рейтинг: 0 / 0
13.03.2007, 15:23
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387563
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
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, как красная тряпка. Ну, уж, извините.
...
Рейтинг: 0 / 0
13.03.2007, 15:29
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387568
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LR
Участник
LRВы можете поделиться с общественностью структурой таблицы dbo.Object? ;)
Понимаю, что эта структура является результатом многолетнего опыта и немалых человекочасов изысканий/тестирования/переделок/проч., поэтому не настаиваю :)

Как и WiRuc, подозреваю, что это - ВЕРО :)
Поэтому позволю себе задать еще один вопрос. Из статьи о ВЕРО: "Реестр содержит информацию об уникальном идентификаторе объекта, типе, состоянии, правах доступа и др., обеспечивая...".
Правильно ли я понимаю, что "Реестр" - это не одна таблица (а несколько базовых)?
...
Рейтинг: 0 / 0
13.03.2007, 15:30
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387571
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
2 Shurgenz

Но только в случаи изменения состояния объекта (точнее сказать экземпляра класса) DML касаются "только его".
...
Рейтинг: 0 / 0
13.03.2007, 15:31
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387599
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
LR LRВы можете поделиться с общественностью структурой таблицы dbo.Object? ;)
Понимаю, что эта структура является результатом многолетнего опыта и немалых человекочасов изысканий/тестирования/переделок/проч., поэтому не настаиваю :)

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

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

Вы совершенно правильно понимаете - ЕРО это не одна таблица, а довольно приличная куча объектов бд и не менее приличная куча кода - это ядро системы, позволяющее разработчику сконцентрироваться на прикладных задачах. Но, это один из возможных вариантов, а не "серебряная пуля".
...
Рейтинг: 0 / 0
13.03.2007, 15:37
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387610
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LR
Участник
Shurgenz pkarklinМдя. Видимо объясняльшик из меня плохой. Хотя вот так, пальцем трудно что-то показать. Надо бы со структурой бд, с кодом. GreenSunrise, WiRuc - процу отправил Вам на мыло. Но, думаю, что она только добавит вопросов.
А мне можно? Временно открыл видимость... Потом закрою, а то спам всякий все больше стал сыпаться
Если можно, и мне?
...
Рейтинг: 0 / 0
13.03.2007, 15:40
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387620
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
LRЕсли можно, и мне?

Коллеги, ну что она вам даст? Проца из 250 строк, в которой идет вызов 1.5 десятков других проц и кучи функций.
...
Рейтинг: 0 / 0
13.03.2007, 15:43
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387637
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
pkarklinМдя. Видимо объясняльшик из меня плохой. Хотя вот так, пальцем трудно что-то показать. Надо бы со структурой бд, с кодом. GreenSunrise, WiRuc - процу отправил Вам на мыло. Но, думаю, что она только добавит вопросов.
Что-то стало понятнее... Непонятно только, почему это подается как ООП, наследование и все такое. Практически то же самое можно сделать с самым обычным реляционным подходом.
...
Рейтинг: 0 / 0
13.03.2007, 15:46
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387660
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
GreenSunrise pkarklin, а вы такую систему имели в виду? У меня сложилось ощущение, что нет.

Конечно же, нет!!! У меня классические сущности с классическими аттрибутами. Т.е. аттрибуты "Дата" и "Номер" сущности "Документ" - это поля DocDate и DocNumber таблицы Document (базовый класс документа), но, которая отношением 1-к-1 связана с таблице Object.
...
Рейтинг: 0 / 0
13.03.2007, 15:50
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387684
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
А мне ответить про насущную необходимость универсального поиска разнотипных сущностей и единого списка статусов?

Просто я и правда пока не вижу необходимости существования единой базовой таблицы.
Общей список статусов может содержать только 1 общий для всех - "удален, больше не нужен". Все остальные статусы уж больно специфичны и практически "не пересекаются".
...
Рейтинг: 0 / 0
13.03.2007, 15:56
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387697
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
GreenSunriseЧто-то стало понятнее... Непонятно только, почему это подается как ООП, наследование и все такое. Практически то же самое можно сделать с самым обычным реляционным подходом.

Еще раз повторюсь - используется классический реляционный подход. А вот поведенческие характеристики системы выглядят, как будто она реализована с использованием ООП. Т.е. выполняются действия для объектов, которые не существуют на момент разработки ядра. Объекты могут иметь характеристики и значения, которые появятся "потом". Даже функция ObjectIs(ID, 'ClassName') ведет себя аналогично дельфиской is - т.е. с учетом наследования.
...
Рейтинг: 0 / 0
13.03.2007, 15:59
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387718
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
DeColo®esА мне ответить про насущную необходимость универсального поиска разнотипных сущностей и единого списка статусов?


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

Единый поиск разнотипных сущестной - не самоцель, хотя такой поиск и существует. В прочем, как и существуют специализированные "поиски" для определенных типов сущностей.
...
Рейтинг: 0 / 0
13.03.2007, 16:04
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387780
GreenSunrise
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GreenSunrise
Участник
Понятно, спасибо. В общем, было интересно ознакомиться с наличием других подходов к проектированию, но на данном этапе развития СУБД с практической точки зрения для меня они неинтересны.
...
Рейтинг: 0 / 0
13.03.2007, 16:22
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387804
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
pkarklinЕдиного списка статусов не существует. Схема состояний (объект) состоит из состояний (объектов). Каджый объект может иметь одну единственную схему состояний.Ну тогда это не такое уж и достоинство. Так, очередной элемент EAV. В одном списке хранятся фактически несколько, никак не связанных по смыслу. Объединенных только общей системой администрирования. Достоинства понятны, недостатки - тоже: независимо от необходимости для конкретного класса, будет проходить проверка возможности смены статуса (наверняка еще и в разрезе системы прав на конкретную смену этого статуса, а возможно еще и с попыткой анализа истории типа "Статус может быть изменен с А на B только при условии, что раньше никогда не встречался статус С")

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

ЗЫ Просто Вы написали про это, как про достоинства. Но пока непонятно, в чем достоинство-то?
...
Рейтинг: 0 / 0
13.03.2007, 16:27
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387880
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
2 pkarklin
Спасибо за пример.
Чуда не произошло, собственно, именно этого я и ожидал. Отход от работы со множествами и переход к процедурной обработке с помощью курсоров. И мне слабо верится, что данный подход может обеспечить равную производительность с "класичесским".
И, насколько, я понимаю FK вы не пользуетесь или пользуетесь ограниченно, т.к. необходимо проверять принадлежность записи к "нужному" классу. А отсутствие FK отрицательно сказывается на возможностях оптимизатора.
Именно всю эту базовую рутину - журнализация, схемы состояний, и т.д. можно спокойно реализовать на таком же уровне без введения родительской таблицы Object. При этом со всеми остальными сущностями работу можно организовывать в классическом варианте.
И еще, использование в селекте dbo.ObjectIs(O.ID,'ExtValueEMail') = 1 опять намекает на переход к процедурному типу программирования.
Конечно, подход может быть интересен с точки зрения упрощения реализации бизнес-логики. Очевидно, надо поработать с ним некоторое и проникнуться всей мощью и гибкостью, чтобы оценить все возможности. Но на первый взгляд, наличие кодогенераторов и базового фреймворка сводят на нет все преимущества ООП в реляционной БД.
P.S. Бросилось в глаза, что вы не закрываете в конце процедуры курсор @MM.
...
Рейтинг: 0 / 0
13.03.2007, 16:44
| Ответить | Цитировать | Написать  
ООП на сервере
    #34387906
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
DeColo®esНу тогда это не такое уж и достоинство. Так, очередной элемент EAV. В одном списке хранятся фактически несколько, никак не связанных по смыслу. Объединенных только общей системой администрирования. Достоинства понятны, недостатки - тоже: независимо от необходимости для конкретного класса, будет проходить проверка возможности смены статуса (наверняка еще и в разрезе системы прав на конкретную смену этого статуса, а возможно еще и с попыткой анализа истории типа "Статус может быть изменен с А на B только при условии, что раньше никогда не встречался статус С")

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

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

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

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

ЗЫ. Если Вы считаете существование такого поиска абсолютна не нужным, я не буду Вас ни в чем убеждать. В конечно итоге - сквозная идентификация объекта в системе в одной таблице это только предпосылка для реализации всего остального функционала ядра.
...
Рейтинг: 0 / 0
13.03.2007, 16:50
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388085
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
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 опять намекает на переход к процедурному типу программирования.
Конечно, подход может быть интересен с точки зрения упрощения реализации бизнес-логики. Очевидно, надо поработать с ним некоторое и проникнуться всей мощью и гибкостью, чтобы оценить все возможности. Но на первый взгляд, наличие кодогенераторов и базового фреймворка сводят на нет все преимущества ООП в реляционной БД.

Да, процедурное программирование.Но, простите, кодогенераторы делают что-то другое? Тогда пардон... Еще раз говорю нет тут никакого ООП. Просто реализация модели как бы обладает свойствами, присущими ООП.
...
Рейтинг: 0 / 0
13.03.2007, 17:26
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388096
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
pkarklinКакой список? Кто с кем не связан, но должен быть связан, по Вашему, по смыслу? И, причем тут администрирование?Списки статусов для разных сущностей не связаны по смыслу. То есть для каждой сущности статус это некий "свой" аттрибут со "своей" смысловой нагрузкой.

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

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

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

ЗЫ На самом деле многие идеи очень интересны. Просто лично мне пока непонятно, зачем привязывать ВСЕ идеи ко всем "объектам".
...
Рейтинг: 0 / 0
13.03.2007, 17:30
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388137
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
DeColo®esА если - нет? Ведь все равно проверка хотя бы необходимости дальнейшей проверки статусов нужна. А если привязать себя намертво к логике именно смены статусов, решение некоторых тривиальных задач получится... перемудреным.

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

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

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

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

Ну, что ж, мне тоже не сразу стало все понятно. Но заложенные в систему идеи деуствительно интересны.
...
Рейтинг: 0 / 0
13.03.2007, 17:38
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388163
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
pkarklinВы готовы со сто процентной уверенностью гарантировать, что "раскрытии" этого кода хп на множественную обработку даст выигрыш. Я нет. Я на 100% не верен, что это можно в принципе раскрыть до "множественной" обработки.Все зависит от задачи. Если в каждой операции обрабатывается 1-2 документа, не больше, то тогда раскрывать особо смысла нет.
Но вот если при одной операции документы обрабатываются десятками....

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

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

Передо мной стоит как раз задача оптимизации как раз такого щасстя.
Работы много, учитывая, что разные типы документов обрабатываются по-разному, но ничего невозможного нет. Насчет возможности раскрытия - как правило, так или иначе есть ИД некой операции, в рамках которой меняются те же документы. Ну вот эту ИД во все процедуры и передавать.
...
Рейтинг: 0 / 0
13.03.2007, 17:43
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388197
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
DeColo®esНо вот если при одной операции документы обрабатываются десятками....

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

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

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

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

Хм... Вы не поверите, я так и делаю, передаю ид операции во все процедуры.
...
Рейтинг: 0 / 0
13.03.2007, 17:49
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388210
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
[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 это не сделаешь, нужен триггер или ХП.
...
Рейтинг: 0 / 0
13.03.2007, 17:52
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388250
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucИмелось в виду, что если FK поле определено в базовой абстрактной сущности (например, "Спецификация табличного документа", ссылка на "Табличный документ") и вы наследуете новые классы, то вам недостаточно ссылаться на Object, необходимо проверять соответствие классов. Иначе, может в результате ошибки программиста оказаться, что запись сущности "Спецификация с/ф" привязана к сущности "Заголовок накладной". Через FK это не сделаешь, нужен триггер или ХП.

Эх... Показать бы это все, чтоб было понятно, что и как...
...
Рейтинг: 0 / 0
13.03.2007, 18:04
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388251
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LR
Участник
WiRucИначе, может в результате ошибки программиста оказаться, что запись сущности "Спецификация с/ф" привязана к сущности "Заголовок накладной". Через FK это не сделаешь, нужен триггер или ХП.
+1, именно этот вопрос я и хотел выяснить, когда говорил о "потере корректности" ссылочной целостности.

И еще, если не секрет :), какого типа идентификатор объектов в ВЕРО? int, bigint(identity) или uniqueidentifier (48 млн - не шутка)?
...
Рейтинг: 0 / 0
13.03.2007, 18:04
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388252
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
bigint
...
Рейтинг: 0 / 0
13.03.2007, 18:05
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388265
Фотография LR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LR
Участник
pkarklinbigint
Понятно, спасибо. А так хотелось увидеть uniqueidentifier!!!
...
Рейтинг: 0 / 0
13.03.2007, 18:09
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388282
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
Сколько ориентировочно потребуется времени на разработку базового функционала ядра?
...
Рейтинг: 0 / 0
13.03.2007, 18:14
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388287
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklinЭх... Показать бы это все, чтоб было понятно, что и как...
Из этого я делаю вывод, что все-таки используется FK?
...
Рейтинг: 0 / 0
13.03.2007, 18:15
| Ответить | Цитировать | Написать  
ООП на сервере
    #34388343
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
pkarklinВ нашей системе документы обрабатываются сотнями за раз (например, при зачислении банковской выписки).

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

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

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

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

Остается только решить вопрос с откатами или выходом по ошибке при нехватке прав пользователя - но и это вполне решаемо.
...
Рейтинг: 0 / 0
13.03.2007, 18:36
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389001
DamirS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DamirS
Участник
pkarklin
Абсолютно никакой денормализации. Повторяю, классическая реляционная модель.

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

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

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

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

Ответ: действительно лажа. Не надо пытаться реализовывать классическую ООП-модель в SQL.
...
Рейтинг: 0 / 0
14.03.2007, 06:27
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389084
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucСколько ориентировочно потребуется времени на разработку базового функционала ядра?

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

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

Безусловно.

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

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

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

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

Множественная обработка не должна быть самоцелью. Порой, решение с помощью курсора будет иметь выигрыш в производительности по сравнению с навороченным запросом. Это уже из моего опыта. ;)
...
Рейтинг: 0 / 0
14.03.2007, 08:28
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389171
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklinЭээ... Ядро уже разработано давно. Так что задача стоит только в наращивании "мяса" на этот скелет. Или Вы что-то другое имели ввиду?

Сколько ориентировочно вашей команде потребовалось человеко-дней на разработку основы ядра? Хочу оценить масштаб работы, если вдруг захочу опробовать такую модель.
...
Рейтинг: 0 / 0
14.03.2007, 09:23
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389180
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucСколько ориентировочно вашей команде потребовалось человеко-дней на разработку основы ядра? Хочу оценить масштаб работы, если вдруг захочу опробовать такую модель.

Я, кажеться, упоминал, что ядро разработано не мной. Я являюсь его "пользователем", хотя кое-что приходилось "править". Так что сказать о сроках точно не могу. Попробую навести справки. :)
...
Рейтинг: 0 / 0
14.03.2007, 09:27
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389213
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
Все-таки, пока мне кажеться, что дальше 3-4 уровня в такой схеме не имеет смысла уходить. Что-то типа 1 - Объект, 2 - абстрактные Справочник, Документ, Табличный документ, 3 - реальные сущности. Дальше уже все больше накладных расходов на поддержание схемы и реальная польза уменьшается.
...
Рейтинг: 0 / 0
14.03.2007, 09:37
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389227
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRucВсе-таки, пока мне кажеться, что дальше 3-4 уровня в такой схеме не имеет смысла уходить. Что-то типа 1 - Объект, 2 - абстрактные Справочник, Документ, Табличный документ, 3 - реальные сущности. Дальше уже все больше накладных расходов на поддержание схемы и реальная польза уменьшается.

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

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

Причем совсем не обязательно, чтобы каждый уровень был "определен" собственной таблицей. Т.е. дочерний объект может "умещаться" в родительской таблице (по аттрибутике сущности, например), но может иметь свою схему состояния (т.е. свои поведенческие характеристики).
...
Рейтинг: 0 / 0
14.03.2007, 09:44
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389243
Фотография DeColo®es
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DeColo®es
Участник
А вообще предложенная идея, включаяя механизм схем состояния - очень интересная.
Главное - не использовать ее ВЕЗДЕ, где надо и не надо. :)
...
Рейтинг: 0 / 0
14.03.2007, 09:48
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389317
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklinПричем совсем не обязательно, чтобы каждый уровень был "определен" собственной таблицей. Т.е. дочерний объект может "умещаться" в родительской таблице (по аттрибутике сущности, например), но может иметь свою схему состояния (т.е. свои поведенческие характеристики).
Это интересный момент. Т.е. не обязательно наследованный объект должен иметь собственную таблицу. Различие сущностей в таблице наверное ведете по классу в Object?
...
Рейтинг: 0 / 0
14.03.2007, 10:10
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389330
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
pkarklinПример с 5ю уровнями:

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

Понятно, что при желании можно сделать и 10 уровень наследования, но все-таки с каждым уровнем увеличивается кол-во вставок, необходимых для создании записи в сущности. Нахождение нескольких сущностей в одной таблице уже несколько меняет это дело.
...
Рейтинг: 0 / 0
14.03.2007, 10:14
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389388
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
WiRuc pkarklinПричем совсем не обязательно, чтобы каждый уровень был "определен" собственной таблицей. Т.е. дочерний объект может "умещаться" в родительской таблице (по аттрибутике сущности, например), но может иметь свою схему состояния (т.е. свои поведенческие характеристики).
Это интересный момент. Т.е. не обязательно наследованный объект должен иметь собственную таблицу. Различие сущностей в таблице наверное ведете по классу в Object?

Есть еще дополнительная таблица - ObjectType - классическое дерево. ;) Object имеет FK на нее.
...
Рейтинг: 0 / 0
14.03.2007, 10:33
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389412
pkarklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
pkarklin
Участник
DeColo®esГлавное - не использовать ее ВЕЗДЕ, где надо и не надо. :)

А он и не используется "везде". Часть сущностей в системе не являются "объектами", т.е. не имеют отношения к таблице Object.
...
Рейтинг: 0 / 0
14.03.2007, 10:37
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389663
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
WiRuc pkarklinПример с 5ю уровнями:

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

Понятно, что при желании можно сделать и 10 уровень наследования, но все-таки с каждым уровнем увеличивается кол-во вставок, необходимых для создании записи в сущности. Нахождение нескольких сущностей в одной таблице уже несколько меняет это дело.Sorry за вмешательство. Выкиньте из схемы pkarklin первый уровень, т.е., "Объект" и получиться с большой степенью вероятности такое же разбиение при стандартном реляционном подходе. Если, конечно, не идти радикальным путем, когда каждый вид контракта рассматривается как отдельная сущность и тогда появятся 10, если не больше, различных невзаимосвязанных таблиц. И тогда возникают сложности для получения сводных отчетов, сложности ссылочного характера, те самые FK.
Спич к тому, что по большому счету, количество "уровней" при такой схеме может не так уж и сильно отличаться от традиционного подхода.
...
Рейтинг: 0 / 0
14.03.2007, 11:35
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389746
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
ChASorry за вмешательство. Выкиньте из схемы pkarklin первый уровень, т.е., "Объект" и получиться с большой степенью вероятности такое же разбиение при стандартном реляционном подходе. Если, конечно, не идти радикальным путем, когда каждый вид контракта рассматривается как отдельная сущность и тогда появятся 10, если не больше, различных невзаимосвязанных таблиц. И тогда возникают сложности для получения сводных отчетов, сложности ссылочного характера, те самые FK.
Спич к тому, что по большому счету, количество "уровней" при такой схеме может не так уж и сильно отличаться от традиционного подхода.
Я понимаю это несколько по-другому. Объектная модель предполагает расширение аттрибутики от уровня к уровню. Т.е., если моделировать скажем накладные, то наверное была бы такая схема в ООП - Объект->Табличный документ->Товарные накладные->Расходные накладные и Объект->Табличный документ->Товарные накладные->Приходные накладные. Если не заморачиваться с ООП, то обычно Приходные и Расходные накладные это просто 2 разные таблицы (с некоторым подмножеством совпадающих полей), либо вообще 1 таблица с полем, определяющим вид накладной. Т.е. в случае ООП кол-во таблиц для описания сущности будет больше.
...
Рейтинг: 0 / 0
14.03.2007, 11:55
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389884
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
WiRucЯ понимаю это несколько по-другому. Объектная модель предполагает расширение аттрибутики от уровня к уровню. Т.е., если моделировать скажем накладные, то наверное была бы такая схема в ООП - Объект->Табличный документ->Товарные накладные->Расходные накладные и Объект->Табличный документ->Товарные накладные->Приходные накладные. Если не заморачиваться с ООП, то обычно Приходные и Расходные накладные это просто 2 разные таблицы (с некоторым подмножеством совпадающих полей), либо вообще 1 таблица с полем, определяющим вид накладной. Т.е. в случае ООП кол-во таблиц для описания сущности будет больше.То, что больше, сомнению не подвергалось, если только не перейти на радикальный EAV, там вообще число таблиц может быть просто фиксировано один раз и навсегда.
Упомянутая Вами схема с накладными действительно проще, но до тех пор, пока не требуются связи между документами, при которых могут возникать ссылки на совершенно разные сущности-документы, при этом, как правило, либо появляются ссылочная целостность на сложных триггерах, учитывающих допустимость даного значения поля-ссылки, и при появлении каждого нового типа документов их придется переписывать, либо куча полей, по которым будет возможно FK, но, возможно, только по одному из них, что потребует дополнительных проверок, если хотим "по честному". И при этом, новой сущность опять же потребует модификацию схемы, меняя количество полей и корректируя проверки.
Сводная отчетность также не добавляет простоты, когда приходиться через union объединять стада разношерстных таблиц, и при появлении новых сущностей опять же будем вынуждены ее переписывать.
Единственный, IMHO, здравый путь для борьбы с этим комом проблем, введение суперсущностей, той или иной степени абстрактности. И в результате, незаметно для себя мы получаем ту же самую иерархию, ну может быть на один-два уровня пониже.
Понятно, что если мы автоматизируем какой-нибудь магазинчик, склад, да мало ли еще чего, то такой подход возможно будет эквивалентом пушки по воробьям. Но когда речь идет об автоматизации крупного холдинга, к примеру, то без иерархии сущностей работы будет больше, IMHO.
В конце концов, компьютеры и сервера должны работать, облегчая нашу жизнь, а не мы все время искать пути, как бы поменьше их загрузить Хотя, допускаю, что мысль выглядит спорной.
...
Рейтинг: 0 / 0
14.03.2007, 12:28
| Ответить | Цитировать | Написать  
ООП на сервере
    #34389984
WiRuc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WiRuc
Гость
ChAУпомянутая Вами схема с накладными действительно проще, но до тех пор, пока не требуются связи между документами, при которых могут возникать ссылки на совершенно разные сущности-документы, при этом, как правило, либо появляются ссылочная целостность на сложных триггерах, учитывающих допустимость даного значения поля-ссылки, и при появлении каждого нового типа документов их придется переписывать, либо куча полей, по которым будет возможно FK, но, возможно, только по одному из них, что потребует дополнительных проверок, если хотим "по честному". И при этом, новой сущность опять же потребует модификацию схемы, меняя количество полей и корректируя проверки.

Для описания необязательных связей между документами достаточно будет в большинстве случаев завести отдельную таблицу связей типа DocLinks с отношением M:M. Конечно, тут уже о проверке ссылочной целостности на FK придется забыть. И я не уверен, что в схеме ООП, эта таблица будет отсутствовать. А при автоматизации все упирается в соотношение быстродействие:гибкость. Хотите максимум производительности - будете рисовать отдельные сущности, ничего не попишешь. Палка о двух концах.
...
Рейтинг: 0 / 0
14.03.2007, 12:59
| Ответить | Цитировать | Написать  
ООП на сервере
    #34390036
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ChA
Участник
WiRucХотите максимум производительности - будете рисовать отдельные сущности, ничего не попишешь. Палка о двух концах.Совершенно верно. Собственно, в этом топике суть была высказана на первой странице, IMHO. Остальное из разряда "верю-не верю", "нужно-не нужно". Нужна гибкость, настраиваемость, минимум вмешательств в схему БД при появлении новых сущностей, выбираете один подход, нужна максимальная производительность - другой. Скажем биллинг я лично не рискнул бы делать по объектно-подобной модели. Но есть достаточно много документоориентированных областей, где она, возможно, может оказаться более предпочтительной.
...
Рейтинг: 0 / 0
14.03.2007, 13:13
| Ответить | Цитировать | Написать  
ООП на сервере
    #34390607
Фотография Shurgenz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shurgenz
Участник
ChA WiRucХотите максимум производительности - будете рисовать отдельные сущности, ничего не попишешь. Палка о двух концах.Совершенно верно. Собственно, в этом топике суть была высказана на первой странице, IMHO. Остальное из разряда "верю-не верю", "нужно-не нужно". Нужна гибкость, настраиваемость, минимум вмешательств в схему БД при появлении новых сущностей, выбираете один подход, нужна максимальная производительность - другой. Скажем биллинг я лично не рискнул бы делать по объектно-подобной модели. Но есть достаточно много документоориентированных областей, где она, возможно, может оказаться более предпочтительной.

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

Если схема будущей БД планирется быть более менее статичной и малоизменяемой, то лучше работать по классической схеме. Редко ведь когда приходится (в большинстве случаев) вносить значительные изменения в структуру БД и в функциональность. Чаще всего из того с чем мне приходится и приходилось работать затрагивало обычно небольшую часть структуры и функциональности, что легко описывалось несложными DDL/DML скриптами (аля патчами).
...
Рейтинг: 0 / 0
14.03.2007, 15:23
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
ООП на сервере
    #36834329
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Добрый день, всем. Наткнулся на топик случайно. Автор того самого подхода я. Точнее не так. Это речь обо мне, но не я автор данного подхода. Также как и pkarklin я унаследовал это от других разработчиков и развиваю.

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

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

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

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

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

Ответ: действительно лажа. Не надо пытаться реализовывать классическую ООП-модель в SQL.

А вот тут позвольте не согласится. Мой схема АБСОЛЮТНО точно такая же как и у pkarklin, вплоть до последнего байта. И я ее успешно использую. Вот уже 4-е приложение разрабатываю на своем фреймворке.
...
Рейтинг: 0 / 0
07.09.2010, 16:05
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834362
мимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мимо
Гость
Old Nick,
а в чём новизна подхода? Букв дюже много - ниасилил. если коротко.
...
Рейтинг: 0 / 0
07.09.2010, 16:19
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834375
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
мимо,

Если честно, лень писать.
...
Рейтинг: 0 / 0
07.09.2010, 16:23
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834382
мимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мимо
Гость
Old Nick,
можно (даже нужно) ссылку на сам принцип.
...
Рейтинг: 0 / 0
07.09.2010, 16:25
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834409
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
мимо,

Попробуйте поискать по хронологии развития

1. Модель Тенцера
2. Ultima-S от Ниеншанц
3. ONTARIO 1 от Тарасова Сергея
4. ONickS от меня

Параллельно развивается NEXUS (хотя может уже не развивается)
...
Рейтинг: 0 / 0
07.09.2010, 16:38
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834451
мимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мимо
Гость
Old Nickмимо,

Попробуйте поискать по хронологии развития

1. Модель Тенцера
2. Ultima-S от Ниеншанц
3. ONTARIO 1 от Тарасова Сергея
4. ONickS от меня

Параллельно развивается NEXUS (хотя может уже не развивается)
Понял, 4 таблицы в базе на все случаи жизни. Утрирую... несколько.
...
Рейтинг: 0 / 0
07.09.2010, 16:59
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834554
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
мимо,

Нет, на каждый класс таблица, с учетом наследования
...
Рейтинг: 0 / 0
07.09.2010, 17:49
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834577
Lepsik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Lepsik
Участник
Old Nickмимо,

Попробуйте поискать по хронологии развития

1. Модель Тенцера
2. Ultima-S от Ниеншанц
3. ONTARIO 1 от Тарасова Сергея
4. ONickS от меня

Параллельно развивается NEXUS (хотя может уже не развивается)

картографическая компания ESRI практикует такой подход.

http://www.esri.com/


Хотя на мой взгляд совершенно зря
...
Рейтинг: 0 / 0
07.09.2010, 17:57
| Ответить | Цитировать | Написать  
ООП на сервере
    #36834578
мимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мимо
Гость
Old Nick,
Если тенцер это: http://foxserver.narod.ru/tenser.htm ? Тогда 4.
...
Рейтинг: 0 / 0
07.09.2010, 17:57
| Ответить | Цитировать | Написать  
ООП на сервере
    #36835006
Фотография Кудряшка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кудряшка
Участник
Помнится, еще лет 8 назад на первой работе мы разрабатывали приложение с подобным подходом к БД. До сих пор считаю его одним из самых красивых решений в разработке которых приходилось участвовать. Да - это было решение/конструктор. Применялось к хоз. деятельности предприятия (бухгалтерия, финансы и анализ).

ИМХО, любую даже самую шикарную идею можно применить так, что будет ужс.

Так что скорее дело не в идее, а в примемении ее с умом.
Это как в математике, выучил сложение, вычитание, умножение и деление - но этого недостаточно, чтобы решить задачу. Чтобы решить задачу, надо эти 4 действия корректно применить.
...
Рейтинг: 0 / 0
08.09.2010, 06:11
| Ответить | Цитировать | Написать  
ООП на сервере
    #36835411
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
мимо,

Надо правильно понимать Тенцера. Он дал направление. Это наследование и сквозной идентификатор. А уж как использовать атрибуты, по Тенцеру или как в ОРМ, дело второе и зависит от задачи. Хотя я склоняюсь ко второму, причем с небольшими вкраплениями первого.
...
Рейтинг: 0 / 0
08.09.2010, 11:22
| Ответить | Цитировать | Написать  
ООП на сервере
    #36835755
мимо
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
мимо
Гость
Old Nick,
а что в методологии концептульного проектирования отсутствует наследование и индентификатор?
...
Рейтинг: 0 / 0
08.09.2010, 13:13
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
ООП на сервере
    #40075035
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кесарь
Участник
Shurgenz,

Код: sql
1.
2.
3.
4.
5.
6.
7.
Create table Object
(
  OID   int identity(1, 1),
  Name  nvarchar(256),
  Class varchar(32) not null,
  Primary key clustered ( OID )
)



почти так. Но, учитывая опыт реальных систем с высокой нагрузкой и понимание работы мс сиквела, вот так:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
Create table Object
(
  OID      bigint identity(1, 1),
  ClassID bigint not null,
  StateID bigint not null,
  Name    varchar(@N*) **not null,
  Primary key clustered ( OID )
)



*значение @N выбирается исходя из условий, вплоть до 8000. Однако рекомендую в центральной таблице иметь небольшое имя, а для хранения полным длинных имён (которые нужны далеко не всем) иметь "присоединяемую" таблицу ObjectFullName (OID bigint not null FK, FullName varchar(8000) not null)
** у объекта принципиально не может не быть имени
...
Рейтинг: 0 / 0
02.06.2021, 13:57
| Ответить | Цитировать | Написать  
ООП на сервере
    #40075038
Кесарь
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кесарь
Участник
Max-xaM
Просто есть программисты-теоретики, а есть программисты-практики.
Пусть попробует прикинуть сколько времени ему понадобится, чтобы имеющуюся БД переделать под новый механизм. А также пусть оценит скорость ее работы в случае, когда БД достигнет 20-30 гигов. Каждый раз обращаться к списку объектов-субъектов.... жуть!


Достаточно забавно читать это спустя так много лет. Я не так давно работал в подобной системе, которую создал один из тутошних участников. Она достигла размера в 16 терабайт и перелопачивала огромный объём инфы ежесекундно. Компания - одна из крупнейших в России в своём секторе и продолжает расти.

Нельзя сказать, что проблем вызванных моделью ВЕРО нет. Есть конечно, но их решают.
...
Рейтинг: 0 / 0
02.06.2021, 14:05
| Ответить | Цитировать | Написать  
139 сообщений из 139, показаны все 6 страниц
  все  
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / ООП на сервере
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=46&tid=1684644]:
 0ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 229ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 266ms
get tp. blocked users:
 1ms
others: 292ms
total:  829ms
созд. / загр.: 829ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]