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

Откуда: Москва
Сообщений: 11310
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]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить