powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / ООП на сервере
14 сообщений из 139, страница 6 из 6
Период между сообщениями больше года.
ООП на сервере
    #36834329
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день, всем. Наткнулся на топик случайно. Автор того самого подхода я. Точнее не так. Это речь обо мне, но не я автор данного подхода. Также как и pkarklin я унаследовал это от других разработчиков и развиваю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.esri.com/


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

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

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

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

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



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

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



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


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

Нельзя сказать, что проблем вызванных моделью ВЕРО нет. Есть конечно, но их решают.
...
Рейтинг: 0 / 0
14 сообщений из 139, страница 6 из 6
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / ООП на сервере
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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