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

Откуда: Питер
Сообщений: 1938
Пришел к нам на работу ДБ девелопер, мне типа в помощь (зачем - непойму, вродеб и так справляюсь)

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

типа

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


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, дабы отличить ссылки на объект от обычных числовых или других идентификаторов.

Create table Subject
(
  OID      int not null,
  Address  nvarchar(2000),
  OwnerOID int, 
  Primary key clustered ( OID )
)
автор
Класс WorkGroup имеет атрибут-коллекцию, состоящую из списка пользователей, входящих в группу. В базе это реализуется в виде такой таблицы:

Create table WorkGroup_Users
(
  OID     int not null,  -- ссылка на WorkGroup (this в C#)
  UserOID int not null,  -- ссылка на пользователя
  Primary key clustered ( OID, UserOID )
)

Create procedure Object_Open
  @OID int
As
  Select * from Object where OID = @OID
Go

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. Наследование методов реализовано в базе данных


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

Или

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
И т.д и т.п.

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

Грит, при подходе с классами можно реализовать логику бизнес процесса... млин, в этот бред даже вникать неохота.
12 мар 07, 14:56    [3887689]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Knyazev Alexey
Member

Откуда: Екб -> Мск
Сообщений: 10233
Блог
Интересный подход
12 мар 07, 15:00    [3887719]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Max-xaM
Member

Откуда: Гусь-Хрустальный
Сообщений: 556
Напоминает мне одного человека.
Как его зовут? Из какой фирмы пришел?
12 мар 07, 15:01    [3887721]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
ну подход как похдод, видел и хуже :) единственное, что не надо его преподносить как единственно верный и пихать везде, где только можно.
12 мар 07, 15:04    [3887741]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
Max-xaM
Напоминает мне одного человека.
Как его зовут? Из какой фирмы пришел?


Я тебе по Мылу отвечу, в форуме не буду...
12 мар 07, 15:06    [3887751]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Max-xaM
Member

Откуда: Гусь-Хрустальный
Сообщений: 556
Shurgenz
Max-xaM
Напоминает мне одного человека.
Как его зовут? Из какой фирмы пришел?


Я тебе по Мылу отвечу, в форуме не буду...

max-xam3k@mail.ru
12 мар 07, 15:06    [3887759]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
Ray D
ну подход как похдод, видел и хуже :) единственное, что не надо его преподносить как единственно верный и пихать везде, где только можно.


вот вот... я только не пойму, как он собирается его продвигать в нашем проекте... а так может быть подход как подход
12 мар 07, 15:07    [3887761]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Max-xaM
Member

Откуда: Гусь-Хрустальный
Сообщений: 556
Просто есть программисты-теоретики, а есть программисты-практики.
Пусть попробует прикинуть сколько времени ему понадобится, чтобы имеющуюся БД переделать под новый механизм. А также пусть оценит скорость ее работы в случае, когда БД достигнет 20-30 гигов. Каждый раз обращаться к списку объектов-субъектов.... жуть!
На прошой работе была не очень большая БД, которую один ботаник захотел переделать под аналогичную структуру. Это у него заняло пол-года, но ничего не сделал. Куча затыков, которые он не смог преодолеть. Результат: крутится та же база, что и была, ботаник научился ее поддерживать.

Так что предложи ему сделать свою и посмотри когда он закончит или скажет что-то типа "У вас гранаты не той системы, ничего не получится". :-)
12 мар 07, 15:12    [3887799]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
ziktuw
Member

Откуда:
Сообщений: 3552
Гибкость обратно пропорциональна производительности. Поэтому к ООП в базах данных нужно подходить очень вдумчиво.

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


----------------------------------------------------------------
Да полно-те Вам. Не стоит благодарности.
12 мар 07, 15:17    [3887812]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
я ему уже задаю вопросики... насколько я понимаю, при ООП при каждом инсерте инсертить придется на самом деле в 2+ таблиц (типа в таблицу связи с родителями тоже)

Удалять и селектить то же самое... уже наводит тоску
12 мар 07, 15:18    [3887826]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
ООП плохо ложиться на реляционную БД. В теории все выглядит красиво, а на практике просто ужас: низкая производительность, проблемы с массовой обработкой записей и т.д. Вот у вас всего 2 уровень наследования, а уже 2 вставки на сущность Subject. Что будет, если иерархия будет n-уровневой?
Вывод: хорошо для общего развития и небольших БД, не оперирующими миллионами записей.
Если есть желание заюзать именно ООП, то нужно смотреть в сторону ОО СУБД.
12 мар 07, 15:19    [3887831]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
MsDatabaseru
Member

Откуда: Hobby.MsDatabase.ru
Сообщений: 10938
скажи ему так
1 что это замечательный подход для разработки принципиально новых проектов в которых требуется унификация для разработчика но не важны фактические показатели быстродействию системы и удобства для дизайна на уровне tsql
2 что на работе подчиненному надо выполнять поставленные задачи, а выбирать концепцию - удел руководителей проектов, обладающих соответствующей квалификацией, хотябы всилу того что всю ответсвенность за реализацию несет именно руководитель и в случае неудач виновать будет он.
3 В случае если нельзя но очень хочется, свои научные или эстетические изыски он может реализовать дома, в свободное от работы время (по другому говоря пусть тренируется на.. кошках)
12 мар 07, 15:20    [3887834]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Shurgenz
Удалять и селектить то же самое... уже наводит тоску


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

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

автор
При таком подходе метод Open класса Subject на сервере приложений перекрывает виртуальный метод класс предка и в начале кода вызывает родительский метод. Таким образом именно сервер приложений обеспечивает совокупный вызов всех методов Open от базового класса до текущего.
12 мар 07, 15:21    [3887839]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Dibrov
Гибкость обратно пропорциональна производительности.

Золотые слова:) Еще со времен ассемблера пошло. Я бы еще добавил " и удобство разработки".
12 мар 07, 15:22    [3887842]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
ООП плохо ложиться на реляционную БД.


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

Сообщение было отредактировано: 12 мар 07, 15:26
12 мар 07, 15:25    [3887859]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
Ну, не все уж так тоскливо. Процедура вставки объекта будет содержать вызов процедуры вставки родительского объекта и INSERT в таблицу самого объекта.

Куда уж тоскливей:) Как минимум 1 лишняя вставка. А максимум не ограничен. И табличка Object родительская, на нее идут все вставки. Может такой затык при массированных вставках случиться:) А уж блокировки... А деадлоки, из-за появления "вертикальной" иерархии...
12 мар 07, 15:29    [3887875]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
pkarklin
Shurgenz
Удалять и селектить то же самое... уже наводит тоску


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

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

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


Может быть для справочных таблиц, в которых не так уж много записей.. А когда таблицы раздуты и они совсем немаленькие... Ведь для каждого объекта, чтоб выбрать информацию, нужно читать иногда из всех его родителей тоже, да + еще WorkGroup_Users - которая осуществляет многие-ко-многим меж ними... и помножить на степень наследования.
12 мар 07, 15:30    [3887882]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
pkarklin
WiRuc
ООП плохо ложиться на реляционную БД.


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

По моему в Дейте как раз и описывалась подобная архитектура. Как раз в разделе объектно-ориентированного подхода.
12 мар 07, 15:34    [3887899]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
WiRuc
pkarklin
WiRuc
ООП плохо ложиться на реляционную БД.


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

По моему в Дейте как раз и описывалась подобная архитектура. Как раз в разделе объектно-ориентированного подхода.


И.... ссылка есть?
12 мар 07, 15:37    [3887922]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Shurgenz
WiRuc
pkarklin
WiRuc
ООП плохо ложиться на реляционную БД.


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

По моему в Дейте как раз и описывалась подобная архитектура. Как раз в разделе объектно-ориентированного подхода.


И.... ссылка есть?

У меня книга
12 мар 07, 15:39    [3887938]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

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

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


Нате:

SELECT
  COUNT(*)
FROM
  dbo.Object

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

(1 row(s) affected)
12 мар 07, 15:46    [3887979]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
tpg
Member

Откуда: Novosibirsk
Сообщений: 23902
Shurgenz
Как его отфутболить поумнее? Лажа ведь какая-то
Ну, например, пусть вспомнит историю возникновения ООП, хотябы утрировано: мол сидела программерская контора и ваяла софт на заказ.
Пока заказчиков было не много и заказы довольно сильно отличались друг от друга, всё шло гладко.
Но вот, повалили заказчики кучей и заказы были как братья близнецы похожи друг на друга, за исключением небольших отличий - кинулись плодить подпрограммы (а ничего ещё кроме процедурного программизма не придумали на то время) и поняли, что так у них под исходники никаких носителей не хватит, да и поддержка такого кода, мяхко говоря - грубо выражаясь...
Вот тут и взялись несколько энтузазистов за "облогараживание" процесса разработки...
Так, или примерно так, и появилось ООП... Красота...
Но, ИМХО, основная цель ООП как была, так и остается - снизить издержки на проектирование софта, но там, где ему не место (РСУБД как раз относится к тем местам, где оно слабо применимо).
Действительно, есть ОО СУБД, вот на них это самое какава. ;-)
Это как параллелизм: 9 женщин не смогут родить за 1 месяц ребенка, но вот за 9 вполне произвести 9.
12 мар 07, 15:47    [3887984]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
ChA
Member

Откуда: Москва
Сообщений: 11308
Shurgenz
Резать, к чортовой матери, не дожидаясь перитонита С такой схемой он вас похоронит. Наверняка практического опыта в реализации подобной подхода у него нет, и учиться он будет на вас, а это может дорого стоить.
12 мар 07, 15:54    [3888037]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
tpg
Member

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

Сообщение было отредактировано: 12 мар 07, 15:58
12 мар 07, 15:58    [3888063]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

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

Я понимаю. У нас конструктивный диалог
pkarklin

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

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

pkarklin

Нате:

SELECT
  COUNT(*)
FROM
  dbo.Object

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

У вас промышленная эксплуатация такой системы? Давайте тогда подробности...
12 мар 07, 15:58    [3888066]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

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


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

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

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

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

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

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


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

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


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

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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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


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

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

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

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

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

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


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

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

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

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


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

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


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

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

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

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

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


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

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

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

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



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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

Откуда: Москва
Сообщений: 5503
Блог
pkarklin
1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой

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

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

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

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

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

На самом деле, универсальные механизмы в п2-4 - действительно нужны. Но для них совсем необязательно для всех объектов заводить общего предка. Хотя его существование в общем-то ничем не мешает, но может стать бутылочным горлышком.
13 мар 07, 11:17    [3890862]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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

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

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


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

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


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

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


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

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


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

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


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

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


Могу еще раз только повторить - я не приподношу это решение, как серебряную пулю.
13 мар 07, 11:45    [3891061]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Я не говорю ничего ни за, ни против наличия базовой таблицы. У нас в свое время была такая идея - сделать базовую таблицу для сущностей, но от этого отказались - побоялись именно того самого бутылочного горлышка.

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

Теперь по упомянутым пунктам
pkarklin
1. Уникальность идентификатора объекта и единое пространство идентификаторов всех прикладных объектов в системе - само собой

Да. Это есть. Но это также может быть легко решено другими способами без базовой таблицы. Например, как WiRuc написал.

pkarklin
2. Унифицированное управление схемами состояний и правилами переходов между состояниями объектов;

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

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

+1 с WiRuc.

pkarklin
4. Общий механизм поддержки расширяемых атрибутов;

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

pkarklin
5. Единую систему журналирования событий;

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

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

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

P.S. Я ни в коем случае ничего не критикую и не против никаких предлагаемых тут решений. Я просто не вижу в них смысла и выигрыша.
13 мар 07, 11:51    [3891112]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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

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

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


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

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


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

Извиняюсь, допишу чуть позже... В офисе свет вырубают...
13 мар 07, 12:04    [3891234]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

Откуда: 8P8C
Сообщений: 2423
to pkarklin
Самым тонким и ответственным вопросом в этом деле мне представляется выбор полей/колонок для "стержневой" таблицы, т.е. какая информация должна содержаться в "стержневой" таблице, а какая выноситься в "хвостовые".
Одна крайность - хранить(регистрировать) в "стержневой" только ID и тип, вторая - напихать туда побольше "якобы общих" полей, вероятно, должна быть какая-то "золотая серединка" (зависящая от назначения системы)?

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

Возможно, как уже здесь отмечали, разумнее существование нескольких "стержневых" таблиц - по одной на каждое "крупное" пространство системы (по функционалу/назначению), например, зачем смешивать метаданные и данные в одной таблице(ведь это приводит к потере корректности ссылочной целостности) и т.п.?
13 мар 07, 12:15    [3891330]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

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


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

Как именно это сделано, поясните, пожалуйста, я не понимаю.

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


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

Значит, я не понимаю понятия "расширенные атрибуты". Объясните, что это такое.
13 мар 07, 12:37    [3891516]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
LR +1
Если это возможно, очень хотелось бы увидеть конкретный код некоторых ХП, например ObjectSetState. Можно на мыло.

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

Я чет уже вообще ничего не понимаю Ну завели мы новый атрибут, но каким таким волшебным образом система узнает о НАЗНАЧЕНИИ этого атрибута и как его использовать в определенных ситуациях. Одно дело, если я на клиенте сразу автоматически могу его просматривать и изменять, тут никаких проблем и ООП для этого не нужен, а другое - его использование в серверной части (я не имею в виду журнализацию, RLS и прочие системные вещи).
13 мар 07, 12:39    [3891531]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
2 GreenSunrise
Вы не одиноки. Я с каждым постом понимаю все меньше и меньше
13 мар 07, 12:43    [3891569]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

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

2Shurgenz
Что делать? Да отправить его на sql-ex.ru и разрешить внедрять свою систему только после прохождения 3-го оптимизационного этапа :)
13 мар 07, 12:53    [3891644]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

Откуда:
Сообщений: 181
кстати, есть еще статейка Анатолия Тенцера про обьектную модель.
Много шума было вокруг этой модели.
Кому интересно - поиск по 'Тенцер' в инете.
13 мар 07, 12:57    [3891677]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

Откуда: Питер
Сообщений: 1938
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 услышать, и про атрибуты не очень понятно, но очень интересно
13 мар 07, 13:24    [3891907]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Naf
Member

Откуда: Москва
Сообщений: 2695
ООП нормально, но только не в том виде, как предлагают: не нужно общую таблицу объектов, достаточно абстрактных классов, описание есть, а реализации нет, а вот в потомках (и то не 1-го уровня) можно и реализовать задекларированное
13 мар 07, 13:39    [3892002]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

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

Насколько я успел в этой всей схеме хоть что-то понять, там именно легкая, а может и не очень легкая степень денормализации...

По-моему, у него всё в тяжелой форме :)
Для снижения нагрузки на сервер специально применяют денормализацию с целью избавиться от join-ов при выборке данных.
Грубый пример: Есть справочник Код-->Название Dict(code int primary key, name varchar(30))
В некоей таблице Table1 есть внешний ключ Dict. Денормализация: в Table1 вместе с внешним ключём Dict помещают так же Dict.name. Именно из-за того, что join - операция затратная

А при такой вот обьектной модели мы грузим сервер join-ами, которых можно избежать просто нормально спроектировав базу.

Поправьте, если не прав.
13 мар 07, 13:45    [3892037]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DamirS
Member

Откуда:
Сообщений: 181
Ага, вот и обсуждение нашёл - страшно подумать - 2002 год!
обсуждение статьи Тенцера
В этой же ветке есть ссылки на сами статьи.
13 мар 07, 13:55    [3892098]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Naf
ООП нормально, но только не в том виде, как предлагают: не нужно общую таблицу объектов, достаточно абстрактных классов, описание есть, а реализации нет, а вот в потомках (и то не 1-го уровня) можно и реализовать задекларированное

Приведите пример, как это делается для баз. Не как это на плюсах пишут :-), а как это на T-SQL выглядит.
13 мар 07, 14:03    [3892142]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
DeColo®es
Member

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


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

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

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

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

А универсальные механизмы для группировок, RLS и прочего прекрасно существуют и без базовой таблицы. Просто в каждом механизме прописывается кроме прочего еще и "класс" объектов, данных которых хранит этот механизм. А если идентификатор объектов - уникальный, то и класс прописывать не всегда обязательно.
13 мар 07, 14:05    [3892158]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Shurgenz
Member

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

Насколько я успел в этой всей схеме хоть что-то понять, там именно легкая, а может и не очень легкая степень денормализации...

По-моему, у него всё в тяжелой форме :)
Для снижения нагрузки на сервер специально применяют денормализацию с целью избавиться от join-ов при выборке данных.
Грубый пример: Есть справочник Код-->Название Dict(code int primary key, name varchar(30))
В некоей таблице Table1 есть внешний ключ Dict. Денормализация: в Table1 вместе с внешним ключём Dict помещают так же Dict.name. Именно из-за того, что join - операция затратная

А при такой вот обьектной модели мы грузим сервер join-ами, которых можно избежать просто нормально спроектировав базу.

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


Джойнов там ровно столько, какой по счету это потомок + пара вспомогательных, опционально, для атрибутов и иерархий. А потомка глубже 4-го уровня придумать в реальной жизни трудновато (мне по крайней мере). Скажем, сущности user & group не есть предок и потомок, а есть иерархия, вроде бы, вроде бы... или старею, или все это для меня, привыкшего к теории множеств на практике, непривычно, а потому не совсем понятно.
13 мар 07, 14:06    [3892162]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
DamirS
Ага, вот и обсуждение нашёл - страшно подумать - 2002 год!
обсуждение статьи Тенцера
В этой же ветке есть ссылки на сами статьи.

Имхо, основной недостаток - о какой-либо бизнес-логике на стороне сервера можно забыть. По меньшей мере, я не представляю вменяемых сторед-прос или триггеров для работы с этим монстром. Триггеров особенно %-)

pkarklin, а вы такую систему имели в виду? У меня сложилось ощущение, что нет.
13 мар 07, 14:21    [3892258]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Коллеги. Свет, наконец то, включили. Отвечу всем по-порядку...
13 мар 07, 14:45    [3892384]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


Ну, чтоб не быть голословным приведу просто скриншот логов одного из объектов (документ)

К сообщению приложен файл. Размер - 0Kb
13 мар 07, 14:53    [3892448]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
И лог контрагента. Все, что логгируется реализовано на базовом уровне.

К сообщению приложен файл. Размер - 0Kb
13 мар 07, 14:54    [3892453]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

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


В базе существует ссылочная целостность. Метаданные и данные в одной табоице не смешаны. Если посмотреть внимательно на структуру бд - классическая реляционная модель.
13 мар 07, 15:02    [3892522]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
stomsky
Member

Откуда: Волгоград
Сообщений: 158
Shurgenz
А потомка глубже 4-го уровня придумать в реальной жизни трудновато (мне по крайней мере).

Хотите подскажу? Справочник для Органа федерального казначейства:

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

И это еще не предел! Хотя при такой иерархии может быть стоит подумать о другой структуре БД? Хотя с другой стороны если в поле "Получатель" платежного поручения может находиться как человек (физ.лицо), так и УФК по Волгоградской области! Т.е. наиболее разумным лично мне кажется отношение 1:М для таблиц "Контрагент" и "Платежные документы" (это я еще не расматриваю способы "размазать" по таблицам документы!).
13 мар 07, 15:07    [3892549]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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


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

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


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

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


Вы глубоко не правы.
13 мар 07, 15:08    [3892557]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
GreenSunrise
Member

Откуда:
Сообщений: 12310
Мне из картинок совершенно непонятно, что и как сделано с логгированием.
13 мар 07, 15:09    [3892563]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
pkarklin
Member

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

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


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

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

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

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


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


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

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


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


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


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

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

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


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


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


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

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


Сорри, тут я ступил. Привидилось DDL, как красная тряпка. Ну, уж, извините.
13 мар 07, 15:29    [3892734]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
LR
Member

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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


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

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

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

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

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

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

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

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


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

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


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

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

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

Откуда: Москва (Муром)
Сообщений: 74930
WiRuc
P.S. Бросилось в глаза, что вы не закрываете в конце процедуры курсор @MM.


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

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

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


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

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


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

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


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

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


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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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


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

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


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

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


Хм... Вы не поверите, я так и делаю, передаю ид операции во все процедуры.
13 мар 07, 17:49    [3893846]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
WiRuc
Member

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

If a name or variable is the last one referencing the cursor, the cursor is deallocated and any resources used by the cursor are freed.
[quot]
Ну да, конечно. Привычка, всегда освобождаю сам.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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


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

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

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

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

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

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


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

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


Безусловно.

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


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

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


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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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


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

Если схема будущей БД планирется быть более менее статичной и малоизменяемой, то лучше работать по классической схеме. Редко ведь когда приходится (в большинстве случаев) вносить значительные изменения в структуру БД и в функциональность. Чаще всего из того с чем мне приходится и приходилось работать затрагивало обычно небольшую часть структуры и функциональности, что легко описывалось несложными DDL/DML скриптами (аля патчами).
14 мар 07, 15:23    [3898021]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: ООП на сервере  [new]
Old Nick
Member

Откуда: Санкт-Петербург
Сообщений: 3177
Добрый день, всем. Наткнулся на топик случайно. Автор того самого подхода я. Точнее не так. Это речь обо мне, но не я автор данного подхода. Также как и pkarklin я унаследовал это от других разработчиков и развиваю.

DamirS
pkarklin

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

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


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

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


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

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

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

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

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


А вот тут позвольте не согласится. Мой схема АБСОЛЮТНО точно такая же как и у pkarklin, вплоть до последнего байта. И я ее успешно использую. Вот уже 4-е приложение разрабатываю на своем фреймворке.
7 сен 10, 16:05    [9398560]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
мимо
Guest
Old Nick,
а в чём новизна подхода? Букв дюже много - ниасилил. если коротко.
7 сен 10, 16:19    [9398675]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Old Nick
Member

Откуда: Санкт-Петербург
Сообщений: 3177
мимо,

Если честно, лень писать.
7 сен 10, 16:23    [9398725]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
мимо
Guest
Old Nick,
можно (даже нужно) ссылку на сам принцип.
7 сен 10, 16:25    [9398755]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Old Nick
Member

Откуда: Санкт-Петербург
Сообщений: 3177
мимо,

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

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

Параллельно развивается NEXUS (хотя может уже не развивается)
7 сен 10, 16:38    [9398867]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
мимо
Guest
Old Nick
мимо,

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

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

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

Понял, 4 таблицы в базе на все случаи жизни. Утрирую... несколько.
7 сен 10, 16:59    [9399061]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Old Nick
Member

Откуда: Санкт-Петербург
Сообщений: 3177
мимо,

Нет, на каждый класс таблица, с учетом наследования
7 сен 10, 17:49    [9399536]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4256
Old Nick
мимо,

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

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

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


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

http://www.esri.com/


Хотя на мой взгляд совершенно зря
7 сен 10, 17:57    [9399601]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
мимо
Guest
Old Nick,
Если тенцер это: http://foxserver.narod.ru/tenser.htm ? Тогда 4.
7 сен 10, 17:57    [9399605]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Кудряшка
Member

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

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

Так что скорее дело не в идее, а в примемении ее с умом.
Это как в математике, выучил сложение, вычитание, умножение и деление - но этого недостаточно, чтобы решить задачу. Чтобы решить задачу, надо эти 4 действия корректно применить.
8 сен 10, 06:11    [9401297]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Old Nick
Member

Откуда: Санкт-Петербург
Сообщений: 3177
мимо,

Надо правильно понимать Тенцера. Он дал направление. Это наследование и сквозной идентификатор. А уж как использовать атрибуты, по Тенцеру или как в ОРМ, дело второе и зависит от задачи. Хотя я склоняюсь ко второму, причем с небольшими вкраплениями первого.
8 сен 10, 11:22    [9402414]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
мимо
Guest
Old Nick,
а что в методологии концептульного проектирования отсутствует наследование и индентификатор?
8 сен 10, 13:13    [9403686]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: ООП на сервере  [new]
Кесарь
Member

Откуда:
Сообщений: 651
Shurgenz,

Create table Object
(
  OID   int identity(1, 1),
  Name  nvarchar(256),
  Class varchar(32) not null,
  Primary key clustered ( OID )
)


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

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)
** у объекта принципиально не может не быть имени
2 июн 21, 13:57    [22330310]     Ответить | Цитировать Сообщить модератору
 Re: ООП на сервере  [new]
Кесарь
Member

Откуда:
Сообщений: 651
Max-xaM
Просто есть программисты-теоретики, а есть программисты-практики.
Пусть попробует прикинуть сколько времени ему понадобится, чтобы имеющуюся БД переделать под новый механизм. А также пусть оценит скорость ее работы в случае, когда БД достигнет 20-30 гигов. Каждый раз обращаться к списку объектов-субъектов.... жуть!


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

Нельзя сказать, что проблем вызванных моделью ВЕРО нет. Есть конечно, но их решают.
2 июн 21, 14:05    [22330314]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6      [все]
Все форумы / Microsoft SQL Server Ответить