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

Откуда:
Сообщений: 653
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

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


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

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