Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
ASCRUS
Я не очень понимаю, как на Java можно работать с логической структурой данных. Если Вы считаете, что обьект в ООП можно назвать логической (чистой) структурой, один в один соотвествущей реальному обьекту в мире, то Вы глубоко ошибаетесь.

Не один в один. Но близко. Гораздо ближе, чем таблица :)
У объекта есть поведение (методы). Фактически объект - это объединение данных и их поведения в одной сущности. Мне это нравится.

ASCRUS
Не возможно спроектировать систему и ее архитектуру без формализации ее структуры и описания ее бизнес-процессов. Все это элементарно делается на РСУБД, где на DDL описываются структуры хранения данных, а на SQL, DML и языке хранимых процедур прописывается бизнес-логика. БД получается законченным самостоятельным модулем системы. Дальнейшая разработка клиентской части - это уже вторичное дело и без разницы на чем ее делать - на ООП языках, веб-технологиях или вообще работать напрямую через ISQL. Соотвествующе пытаться подогнать СУБД только под критерий "чтоб было удобно одной из технологии разработки клиентских приложений" мне кажется не рациональным.

Есть разные подходы. Лично я считаю, что объектный подход хорош.
Есть задачи, когда данные надо отделить от приложения.
Но опять же, у данных есть поведение. Это не просто набор таблиц. Приходится писать скрипты, триггера, задавать констрейнты...
Вполне возможно сделать это в рамках приложения и описать некий интерфейс работы данными посредством приложения. Ведь закачивая данные в Oracle фактически пользователю навязывается это приложение (сама СУБД) для работы с данными. Разве не так?
17 дек 04, 14:50    [1189398]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Lankaster
AI

Почему та же ER-модель не объектна? Потому что нет наследования и методов?

Как минимум поэтому.


Вот тут-то Вы, Штирлиц, и попались. Матчасть надо учить. Как Вы объясните наличие сущностей супертип-подтип в ER-модели? Подтип наследует атрибуты супертипа и является одновременно экземпляром и супертипа, и подтипа.

Далее.

Lankaster
www.fun4me.narod.ru


Дело в том, что одни и те же данные могут быть представлены как совершенно различные объекты в зависимости от точки зрения пользователя. Следовательно, мапинга Вам избежать не удастся. А так как вы точку зрения одного приложения (одной маленькой и ничтожной частички большой и прекрасной системы) делаете основной, то Вы затрудняете работу других приложений с теми же данными.


Значит это разные классы.


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

Lankaster
tygra

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


А сервер приложений это тоже клиент?


Разумеется! А что же по-вашему? Сервер СУБД? Опять-таки, матчасть надо учить.
17 дек 04, 14:52    [1189414]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
ASCRUS

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

Ну, это уже вопрос вкусов :)
А получить данные о длине хвоста человека - вполне нормально. Она равна 0. Как правило :)
17 дек 04, 14:53    [1189418]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
AI

Вот тут-то Вы, Штирлиц, и попались. Матчасть надо учить. Как Вы объясните наличие сущностей супертип-подтип в ER-модели? Подтип наследует атрибуты супертипа и является одновременно экземпляром и супертипа, и подтипа.

А методы? :)
AI

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

Классы разные, а данные одни. Кто мешает строить связи между классами и аттрибутами?

AI

Lakaster

А сервер приложений это тоже клиент?

Разумеется! А что же по-вашему? Сервер СУБД? Опять-таки, матчасть надо учить.

А вот тут, батенька, я с вами не соглашусь...
Для СУБД сервер приложений клиент. А в рамках всего клиент-серверного приложения - однозначно сервер!
Не ту матчасть учите :)
17 дек 04, 15:01    [1189469]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Есть разные подходы. Лично я считаю, что объектный подход хорош.
Есть задачи, когда данные надо отделить от приложения.

Мне казалось всегда, что так и должно обычно быть. Иначе зачем вам вообще СУБД?
автор
Но опять же, у данных есть поведение. Это не просто набор таблиц. Приходится писать скрипты, триггера, задавать констрейнты...

Так вам не хочется писать это все?
Или вы не умеете на sql чего-то писать?
Или кроме Java больше не на чем? (Как же я ненавижу Java :))
автор
Вполне возможно сделать это в рамках приложения и описать некий интерфейс работы данными посредством приложения.

Зачем? Для этого есть средства у СУБД. Мне система, которая без клиента ничего из себя не представляет, нафиг не нужна. Да и большинству тоже. Хотя для тех, что продает такие решения, выход хорош - только через них можно чего-то сделать с данными. Хотя бы те же отчеты.
автор
Ведь закачивая данные в Oracle фактически пользователю навязывается это приложение (сама СУБД) для работы с данными. Разве не так?

Не понял этого предложения.


ЗЫ И что только люди не напишут, чтобы оправдать неприжившийся продукт вследствие его неконкурентноспособности.

=====
Еще раз определимся :)
Зачем вам данные в виде объекта?
Пока понятно только вот это:
1. Либо вы не умеете по-другому, ну может просто не умеете на sql ХП, Триггеры писать или вообще с СУБД работать - сами говорили, что все само делается/хранится/используется, любой ламер типа может работать и т.д.
2. Либо ... ??? Ыыыы...

Так вот хоть один пример приведите, с объектом данных, почему он лучше и т.д.

А интерсно, действительно, если РСУБД позволяет представлять данные как я хочу - в одном месте у "объекта" такие свойства, в другом другие, то с ООСУБД как? Объект то уже есть - к нему ничего не добавишь/не убавишь в процессе работы с данными :)

-- Tygra's --
17 дек 04, 15:09    [1189509]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Про сервер приложений давайте не будем в этом топике, лучшие старый продолжим, там и так полсотни страниц, ну еще столько же добавим... Только не тут

-- Tygra's --
17 дек 04, 15:11    [1189516]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
tygra
Про сервер приложений давайте не будем в этом топике, лучшие старый продолжим, там и так полсотни страниц, ну еще столько же добавим... Только не тут

Ок
17 дек 04, 15:13    [1189533]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
www.fun4me.narod.ru

Абонент {
Строка имя
Адрес регистрация
Контракт[] контракты
}

Контракт {
Дата начало_действия
Дата конец_действия
Оконечное_устройство[] устройства
}

Оконечное_устройство {
Тип тип
}


Задача: Найти имена всех абонентов с московской регистрацией, у которых в период с 2002-09-01 по 2002-09-30 было не менее трёх открытых контрактов на устройства заданного типа.

Итак считаем время:
SQL:
select Абонент.имя, count(Контракт.КонтрактID) from Абонент
inner join Контракт On Контракт.АбонентID=Абонент.АбонентID and (Контракт.начало_действия between 2002-09-01 and 2002-09-30 or
Контракт.конец_действия between 2002-09-01 and 2002-09-30)
inner join Список_связей on Список_связей.КонтрактID = Контракт.КонтрактID
inner join Оконечное_устройство on Оконечное_устройство.id = Список_связей.Оконечное_устройствоID and Оконечное_устройство.тип = 'тип'
where Абонент.регистрация = 'Москва'
group by (Абонент.имя)
having count(Контракт.КонтрактID)
уф, вроде так...
Исходим из следующих предположений
1. програмисты гении и построили ВСЕ нужные индексы правильных типов.
2. В таблицах Абонент, Контракт,Оконечное_устройство и Список_связей соответственно n,m,k,l записей. записей в таблице Абонент с регистрацией Москва 80%, устройств заданного типа 10%
3. SQL работает оптимально, все запросы уже скомпелированы и т.д.
Время исполнения вычисляется так
a. использование btree индекса по полю регистрация O()log2(n)
b. использование btree индекса по полю Контракт.АбонентID O()log2(m)
c. использование btree индекса по полям Контракт.начало_действия и Контракт.конец_действия O()2*log2(m)
d. если в таблице связи сделать btree индекс по двум полям, то возможно, он сможет его использовать 1 раз для связи таблиц Контракт и Оконечное_устройство отсюда в идеале имеем: O()log2(l)
e. фильтрация Оконечное_устройство.тип = 'тип' O()log2(k)
17 дек 04, 15:13    [1189536]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
AI
Member

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

AI

Lakaster

А сервер приложений это тоже клиент?

Разумеется! А что же по-вашему? Сервер СУБД? Опять-таки, матчасть надо учить.

А вот тут, батенька, я с вами не соглашусь...
Для СУБД сервер приложений клиент. А в рамках всего клиент-серверного приложения - однозначно сервер!
Не ту матчасть учите :)


Тогда надо говорить не о клиент-серверных технологиях, а о многозвенных. И говорим мы именно о СУБД, объектных или не совсем. И сервер приложений - самый обычный клиент.

Матчасть-то я учу нужную.
17 дек 04, 15:14    [1189540]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Guest_New
Guest
tygra
А интерсно, действительно, если РСУБД позволяет представлять данные как я хочу - в одном месте у "объекта" такие свойства, в другом другие, то с ООСУБД как? Объект то уже есть - к нему ничего не добавишь/не убавишь в процессе работы с данными :)

-- Tygra's --


Можно подробнее. Что значит представить данные как я хочу. Изменить схему?
Или Вы имеете ввиду написать SELECT?
17 дек 04, 15:24    [1189597]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
tygra

Отсюда вывод: нужно побыстрее определиться, о чем же речь, о специальных приложениях, или обо всех?
Если специальных - то смысла в обсуждении нет, т.к. можно найти такие специальные приложения, где любая СУБД будет медленнее какого-то своего решения.

Речь идет о типах приложений. Например, геоинформационные системы. Самих приложений много может быть - вопрос инфо потребностей. Поэтому имеет смысл. И медленность не всегда главное. Я писал выше пример.

Lankaster

Данные - это всего лишь один из аспектов проблемы. Ведь суть приложения не чтение и сохранение данных, а их обработка. В основном суть информационной системы - автоматизация процессов, поведения данных.
ИМХО

Однако, более традиционно считается, что целью информационной системы является удовлетворение информационных потребностей. Объектное проектирование дает преимущество более точного и естественного моделирования за счет поведения объектов. Однако, это преимущество может оказаться незначительным в приложении, а преимущества РМД существенными. Т.е. преимуществ и недостатков несколько у разных подходов. Имеет значение все-таки - как они проявляются на конкретных типах приложений. В бизнес приложениях преимущества РМД слишком высоки – простота моделирования, и простота получения нужной информации. Вот там где эти преимущества РМД не очень проявляются или наоборот, там другое дело.
Константин Лисянский


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

Может там не ясно прозвучало – РМД, а не РСУБД. Т.е. ROLAP – это уже не РМД. Там моделируются не сущности. Там есть измерения, таблицы фактов. Это не РМД. Но поддерживает это и MOPAP – РСУБД. Например, Оракл. Я и пытался об этом сказать. Речь шла о том, что не следует понимать под современными РСУБД – СУБД, которые поддерживают только РМД. Т.е. задача у сторонников ООСУБД сложнее, чем бороться только с РМД,
17 дек 04, 15:34    [1189641]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Виталий Гаврилов
Member

Откуда: Санкт-петербург
Сообщений: 15
www.fun4me.narod.ru

Абонент {
Строка имя
Адрес регистрация
Контракт[] контракты
}

Контракт {
Дата начало_действия
Дата конец_действия
Оконечное_устройство[] устройства
}

Оконечное_устройство {
Тип тип
}


Задача: Найти имена всех абонентов с московской регистрацией, у которых в период с 2002-09-01 по 2002-09-30 было не менее трёх открытых контрактов на устройства заданного типа.

Итак считаем время:
SQL:
select Абонент.имя, count(Контракт.КонтрактID) from Абонент
inner join Контракт On Контракт.АбонентID=Абонент.АбонентID and (Контракт.начало_действия between 2002-09-01 and 2002-09-30 or
Контракт.конец_действия between 2002-09-01 and 2002-09-30)
inner join Список_связей on Список_связей.КонтрактID = Контракт.КонтрактID
inner join Оконечное_устройство on Оконечное_устройство.id = Список_связей.Оконечное_устройствоID and Оконечное_устройство.тип = 'тип'
where Абонент.регистрация = 'Москва'
group by (Абонент.имя)
having count(Контракт.КонтрактID)
уф, вроде так...
Исходим из следующих предположений
1. програмисты гении и построили ВСЕ нужные индексы правильных типов.
2. В таблицах Абонент, Контракт,Оконечное_устройство и Список_связей соответственно n,m,k,l записей. записей в таблице Абонент с регистрацией Москва 80%, устройств заданного типа 10%, фильтрация по датам дана нам 10% от k
3. SQL работает оптимально, все запросы уже скомпелированы и т.д.
Время исполнения вычисляется так
a. использование btree индекса по полю регистрация O()log2(n)
b. использование btree индекса по полю Контракт.АбонентID O()log2(m)
c. использование btree индекса по полям Контракт.начало_действия и Контракт.конец_действия O()2*log2(m)
d. если в таблице связи сделать btree индекс по двум полям, то возможно, он сможет его использовать 1 раз для связи таблиц Контракт и Оконечное_устройство отсюда в идеале имеем: O()log2(l)
e. фильтрация Оконечное_устройство.тип = 'тип' O()log2(k)
плюс агрегация следующего количества записей по одному полю
0.8*n * 0.1 * m * 0.1 * k это конечно очень грубо но гдето так.
функцию на агрегирование уже не помню, давно было.
Предположим что мы получили t записей соответственно фильтрация займет O()t
итого O()(log2(n)+3*log(m)+log2(l)+log2(k)+t)
В следующем топике попропую просчтать под ОБД, если кто поможет, буду благодарен.
PS. предыдущий пост с темже началом можно незамечать.
17 дек 04, 15:48    [1189695]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
tygra
Мне казалось всегда, что так и должно обычно быть. Иначе зачем вам вообще СУБД?

В том то и дело, что мне она не нужна.
tygra
Или вы не умеете на sql чего-то писать?

Я честно признаюсь, что вообще не программист
Я скорее заказчик.
На sql писать, тем не менее, могу. Но не хочу. Я не хочу отделять данные от приложения. Какие преимущества это дает?
tygra
Или кроме Java больше не на чем? (Как же я ненавижу Java :))

И не только на Java... :)

tygra
автор
Ведь закачивая данные в Oracle фактически пользователю навязывается это приложение (сама СУБД) для работы с данными. Разве не так?

Не понял этого предложения.

СУБД - тоже приложение в конечном итоге. Для работы с данными.

tygra

ЗЫ И что только люди не напишут, чтобы оправдать неприжившийся продукт вследствие его неконкурентноспособности.

Я бы не был так категоричен в оценках. Посмотрим.

tygra

любой ламер типа может работать и т.д.

Я, кстати, говорил ровно противоположное.

tygra

А интересно, действительно, если РСУБД позволяет представлять данные как я хочу - в одном месте у "объекта" такие свойства, в другом другие, то с ООСУБД как? Объект то уже есть - к нему ничего не добавишь/не убавишь в процессе работы с данными :)

Я понимаю, можно написать приложение так, что при изменении физической структуры данных не меняется код приложения. Но это требует по меньшей мере большой универсализации методов работы с данными. Читай - потеря гибкости и скорости.
Как правило же менять приходится и базу и приложение.
ООСУБД фактически незаметна при изменении. Меняете описание классов, логику их работы - трансформируется технология их храниения (автоматически либо согласно заданных программистом алгоритмов). А не наоборот, когда меняются данные, а потом под них адаптируется приложение.
17 дек 04, 15:55    [1189723]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Виталий Гаврилов
Итак считаем время:
SQL:
select Абонент.имя, count(Контракт.КонтрактID) from Абонент
inner join Контракт On Контракт.АбонентID=Абонент.АбонентID and (Контракт.начало_действия between 2002-09-01 and 2002-09-30 or
Контракт.конец_действия between 2002-09-01 and 2002-09-30)
inner join Список_связей on Список_связей.КонтрактID = Контракт.КонтрактID
inner join Оконечное_устройство on Оконечное_устройство.id = Список_связей.Оконечное_устройствоID and Оконечное_устройство.тип = 'тип'
where Абонент.регистрация = 'Москва'
group by (Абонент.имя)
having count(Контракт.КонтрактID)
уф, вроде так...
Исходим из следующих предположений
1. програмисты гении и построили ВСЕ нужные индексы правильных типов.
2. В таблицах Абонент, Контракт,Оконечное_устройство и Список_связей соответственно n,m,k,l записей. записей в таблице Абонент с регистрацией Москва 80%, устройств заданного типа 10%
3. SQL работает оптимально, все запросы уже скомпелированы и т.д.
Время исполнения вычисляется так
a. использование btree индекса по полю регистрация O()log2(n)
b. использование btree индекса по полю Контракт.АбонентID O()log2(m)
c. использование btree индекса по полям Контракт.начало_действия и Контракт.конец_действия O()2*log2(m)
d. если в таблице связи сделать btree индекс по двум полям, то возможно, он сможет его использовать 1 раз для связи таблиц Контракт и Оконечное_устройство отсюда в идеале имеем: O()log2(l)
e. фильтрация Оконечное_устройство.тип = 'тип' O()log2(k)



По-моему, задача эта была для ООСУБД. Как на РСУБД это сделать и так вполне понятно.
К слову, индекс по регистрации в Москве низкоселективный. Будет full scan - O(n). Но он будет быстрее выборки по индексу из-за меньшего количества операций ввода-вывода. Каковые я бы и попробовал сосчитать для оценки времени выполнения, а не количество строк.

С уважением,
Константин Лисянский
http://lissianski.narod.ru
17 дек 04, 15:59    [1189740]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
vadiminfo
Может там не ясно прозвучало – РМД, а не РСУБД. Т.е. ROLAP – это уже не РМД. Там моделируются не сущности. Там есть измерения, таблицы фактов. Это не РМД. Но поддерживает это и MOPAP – РСУБД. Например, Оракл. Я и пытался об этом сказать. Речь шла о том, что не следует понимать под современными РСУБД – СУБД, которые поддерживают только РМД. Т.е. задача у сторонников ООСУБД сложнее, чем бороться только с РМД,


Ну, да в принципе понятно, что Вы имели в виду. Вы лишь немного смешали понятия из разных моделей. Дело в том, что многомерная модель (по вашему OLAP) не оперирует таблицами (это я о таблицах фактов). Там есть измерения и показатели. Соответственно, речь идёт об анализе показателей в разрезе различных измерений (в самом примитивном понимании этой модели). Если мне не изменяет мой склероз, старина Кодд не упоминал ничего о том, как эта ЛОГИЧЕСКАЯ модель должна быть организована. Например, MDDB (multidimensional database) реализует эту модель физически отлично от того, какую модель использует РСУБД. ROLAP же полагается на РСУБД для хранения данных, пользователю же представляет данные в многомерном виде, а обработка данных может вестись на сервере РСУБД ("чистый" ROLAP, так и на сервере OLAP в случае HOLAP).
В целом всё верно. Просто я счёл необходимым поправить детали. Надеюсь, кому-то помогло :)

А как хранят данные ООСУБД я даже и не знаю. Может, кто-то просветит?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
17 дек 04, 16:10    [1189775]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
AI
Тогда надо говорить не о клиент-серверных технологиях, а о многозвенных. И говорим мы именно о СУБД, объектных или не совсем. И сервер приложений - самый обычный клиент.

Хорошо, будем считать, что нас интересуют только отношения СУБД и ближнего к ней звена приложения.
То есть насколько я понял, есть некая необходимость (или просто желание) хранить бизнес-логику в Oracle, MS SQL или другой СУБД (не обязательно реляционной)? И это кажется более предпочтительным, нежели в собственном приложении? Мне нет. Я понимаю, что есть определенные стереотипы, выработанные практикой. И определенно, СУБД обладают мощными средствами обработки данных.
Но мне нравится чистый объектный подход. Мне нравится JDO, дающая возможность абстрагироваться от формата хранения данных. Вся моя логика - в моем приложении. Я могу работать с реляционной базой, если у клиента она уже есть и он не готов платить за объектную. Могу повысить эффективность за счет переключения на объектную. Это та свобода, которая мне нужна.
И если при этом я получу всю ту функциональность, которую дают популярные сегодня СУБД, то why бы и not...
17 дек 04, 16:10    [1189779]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Константин Лисянский

Дело в том, что многомерная модель (по вашему OLAP) не оперирует таблицами (это я о таблицах фактов).

Наверно, я опять не ясно выразился.
По моему - OLAP это не модель вообще. Таблицей фактов оперирует ROLAP, а многомерный формат это MOLAP. И оба они Олапы, и оба есть в РСУБД Оракл или как он себя сам называет ОРСУБД. Т.е. по моему - многомерный формат (а не модель данных) - MOLAP, а ROLAP оперирует измерниями и таблицами фактов, которые стоятся на рел таблицах, но не есть РМД, в которой моделируются сущности. Обе поддерживаются РСУБД.
17 дек 04, 16:33    [1189857]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Lankaster
AI
Тогда надо говорить не о клиент-серверных технологиях, а о многозвенных. И говорим мы именно о СУБД, объектных или не совсем. И сервер приложений - самый обычный клиент.

Хорошо, будем считать, что нас интересуют только отношения СУБД и ближнего к ней звена приложения.
То есть насколько я понял, есть некая необходимость (или просто желание) хранить бизнес-логику в Oracle, MS SQL или другой СУБД (не обязательно реляционной)? И это кажется более предпочтительным, нежели в собственном приложении? Мне нет. Я понимаю, что есть определенные стереотипы, выработанные практикой. И определенно, СУБД обладают мощными средствами обработки данных.
Но мне нравится чистый объектный подход. Мне нравится JDO, дающая возможность абстрагироваться от формата хранения данных. Вся моя логика - в моем приложении. Я могу работать с реляционной базой, если у клиента она уже есть и он не готов платить за объектную. Могу повысить эффективность за счет переключения на объектную. Это та свобода, которая мне нужна.
И если при этом я получу всю ту функциональность, которую дают популярные сегодня СУБД, то why бы и not...

Гм. Дело в том, что я собственным приложением считаю БД и уж никак не какое то звено (база первична, все остальное вторично). И там мне не надо думать о таких понятиях, как абстрагироваться, формат хранения данных. И я вообще не понимаю, что такое чистый обьектный подход. Вся моя логика в БД, я могу красиво и мощно работать с данными, не задумываясь об алгоритмах их обработки, могу повысить эффективность методом граммотного проектирования БД. Это как раз та свобода, которая мне нужна и мне совсем не нужны те функции, которые предоставляют ООП языки для решения стандартных задач. Если клиент сильно навороченный не нужен, то я вообще просто у РСУБД запускаю поддержку встроенного веб-сервера и по HTML макетам рисую формы ввода/вывода информации для браузера на тех же хранимых процедурах, где в итоге вся программа состоит из запущенного РСУБД, БД и обычного браузера у клиента.
17 дек 04, 16:35    [1189863]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Lankaster
AI
Тогда надо говорить не о клиент-серверных технологиях, а о многозвенных. И говорим мы именно о СУБД, объектных или не совсем. И сервер приложений - самый обычный клиент.

Хорошо, будем считать, что нас интересуют только отношения СУБД и ближнего к ней звена приложения.
То есть насколько я понял, есть некая необходимость (или просто желание) хранить бизнес-логику в Oracle, MS SQL или другой СУБД (не обязательно реляционной)? И это кажется более предпочтительным, нежели в собственном приложении? Мне нет. Я понимаю, что есть определенные стереотипы, выработанные практикой. И определенно, СУБД обладают мощными средствами обработки данных.


А просто мы СУБД и обсуждаем. Вы же все время пытаетесь абстрагироваться от СУБД в пользу обработки, но не хранения.

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

Последнее. Подход "приложение будет работать с любой базой, если та поддерживает интерфейс ххх" страдает одним пороком. Всегда неявно при написании приложения будет подразумеваться оптимизация под одну конкретную СУБД - ту на которой в настоящий момент система пишется. И на другой СУБД приложение будет работать или плохо, или даже не работать совсем. И уж тогда придется отказаться практически от всех возможностей СУБД, в том числе и для ускорения работы. То есть о хорошей производительности можно будет говорить только при использовании "неявной" СУБД и забыть о производительности для всех других, хотя "приложение может с ними работать". Подход "поставим более мощную железку" тоже может не помочь. Для примера рекомендую прочитать первые две главы книги Т. Кайта "Оракл для профессионалов". Там рассматривается именно ошибка не учета особенностей оракула, которая привела к неработоспособности системы вне зависимости от производительности сервера.
17 дек 04, 16:37    [1189873]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
ASCRUS
Гм. Дело в том, что я собственным приложением считаю БД и уж никак не какое то звено (база первична, все остальное вторично).

БД - это данные. Приложением является их представление в конкретной СУБД. Так?
ASCRUS

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

А что значит "красиво и мощно работать"? Это не обработка данных?
Просто одним из методов обработки данных является обработка их средствами СУБД. Причем практически всегда этого не хватает.
Есть и другие подходы. Я именно об этом говорю. Понимая, что другие подходы не всегда оправданы.
ASCRUS

Если клиент сильно навороченный не нужен, то я вообще просто у РСУБД запускаю поддержку встроенного веб-сервера и по HTML макетам рисую формы ввода/вывода информации для браузера на тех же хранимых процедурах, где в итоге вся программа состоит из запущенного РСУБД, БД и обычного браузера у клиента.

То есть пользователь через браузер напрямую с базой работает? Ню-ню...
17 дек 04, 16:47    [1189915]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
А что значит "красиво и мощно работать"? Это не обработка данных?
Просто одним из методов обработки данных является обработка их средствами СУБД. Причем практически всегда этого не хватает.
Есть и другие подходы. Я именно об этом говорю. Понимая, что другие подходы не всегда оправданы.

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

автор
То есть пользователь через браузер напрямую с базой работает? Ню-ню...

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

А вообще получается, что вы пришли туда, откуда все уже давно ушли. И ваш метод очень похож на FoxPro 2.6 for DOS, только с ООП - все то же: логика внутри клиента, данные там же практически, обработка данных там же.... Регрессия, однако? :)

=====
Ну хоть один пример, зачем это все????????

-- Tygra's --
17 дек 04, 17:01    [1189982]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Lankaster

БД - это данные. Приложением является их представление в конкретной СУБД. Так?

Скажем так - БД - это данные и бизнес-логика, представленные в конкретной СУБД (из за разности диалектов производителей СУБД).

Lankaster
А что значит "красиво и мощно работать"? Это не обработка данных?
Просто одним из методов обработки данных является обработка их средствами СУБД. Причем практически всегда этого не хватает.
Есть и другие подходы. Я именно об этом говорю. Понимая, что другие подходы не всегда оправданы.

Практически мне всегда хватает обрабатывать данные средствами СУБД. Поэтому дайте определение термину "обработка данных".

Lankaster

То есть пользователь через браузер напрямую с базой работает? Ню-ню...

Угу - он родимый и работает по 80-ому порту. Через встроенные в РСУБД веб-сервисы, систему защиты и прав, посредством вызовов хранимых процедур. Причем остальные порты вообще можно закрыть, если к БД требуется доступ только через веб-сервисы. Что тут Вы конкретно видите плохого ?
17 дек 04, 17:02    [1189986]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Константин Лисянский
Виталий Гаврилов
Итак считаем время:
SQL:
select Абонент.имя, count(Контракт.КонтрактID) from Абонент
inner join Контракт On Контракт.АбонентID=Абонент.АбонентID and (Контракт.начало_действия between 2002-09-01 and 2002-09-30 or
Контракт.конец_действия between 2002-09-01 and 2002-09-30)
inner join Список_связей on Список_связей.КонтрактID = Контракт.КонтрактID
inner join Оконечное_устройство on Оконечное_устройство.id = Список_связей.Оконечное_устройствоID and Оконечное_устройство.тип = 'тип'
where Абонент.регистрация = 'Москва'
group by (Абонент.имя)
having count(Контракт.КонтрактID)
уф, вроде так...
Исходим из следующих предположений
1. програмисты гении и построили ВСЕ нужные индексы правильных типов.
2. В таблицах Абонент, Контракт,Оконечное_устройство и Список_связей соответственно n,m,k,l записей. записей в таблице Абонент с регистрацией Москва 80%, устройств заданного типа 10%
3. SQL работает оптимально, все запросы уже скомпелированы и т.д.
Время исполнения вычисляется так
a. использование btree индекса по полю регистрация O()log2(n)
b. использование btree индекса по полю Контракт.АбонентID O()log2(m)
c. использование btree индекса по полям Контракт.начало_действия и Контракт.конец_действия O()2*log2(m)
d. если в таблице связи сделать btree индекс по двум полям, то возможно, он сможет его использовать 1 раз для связи таблиц Контракт и Оконечное_устройство отсюда в идеале имеем: O()log2(l)
e. фильтрация Оконечное_устройство.тип = 'тип' O()log2(k)



По-моему, задача эта была для ООСУБД. Как на РСУБД это сделать и так вполне понятно.
К слову, индекс по регистрации в Москве низкоселективный. Будет full scan - O(n). Но он будет быстрее выборки по индексу из-за меньшего количества операций ввода-вывода. Каковые я бы и попробовал сосчитать для оценки времени выполнения, а не количество строк.

С уважением,
Константин Лисянский
http://lissianski.narod.ru


Имхо, преимущества ООСУБД можно увидеть, если повнимательнее взглянуть на пункты b и d. Ведь в случае ООСУБД все контракты конкретного абонента окажутся доступны через механизм непосредственной навигации, т.е. никакого перебора индексов не потребуется.
В остальном ООСУБД будут работать также, как и РСУБД (т.е. индексация по полям поиска здесь работает аналогично).
17 дек 04, 17:02    [1189987]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
Lankaster
Member

Откуда:
Сообщений: 34
AI
А просто мы СУБД и обсуждаем. Вы же все время пытаетесь абстрагироваться от СУБД в пользу обработки, но не хранения.

Не совсем так. Я говорю о том, что можно сосредоточиться на обработке данных, уделяя меньше внимания хранению. ООСУБД дают такие возможности.
AI

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

http://factiva.com работает на ООСУБД. Их база - несколько терабайт.
AI

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

Все это давно уже реализовано не только в реляционных базах данных. Транзакции, индексы, оптимистичные и пессимистичные блокировки, версионность....
AI

Последнее. Подход "приложение будет работать с любой базой, если та поддерживает интерфейс ххх" страдает одним пороком. Всегда неявно при написании приложения будет подразумеваться оптимизация под одну конкретную СУБД - ту на которой в настоящий момент система пишется. И на другой СУБД приложение будет работать или плохо, или даже не работать совсем. И уж тогда придется отказаться практически от всех возможностей СУБД, в том числе и для ускорения работы. То есть о хорошей производительности можно будет говорить только при использовании "неявной" СУБД и забыть о производительности для всех других, хотя "приложение может с ними работать".

Не совсем так. Если мы говорим о JDO, то существует масса реализаций, которые достаточно эффективно работают с разными СУБД. Да, есть потери от универсализации. Но потери от самостоятельного написания прослойки для маппинга гораздо существеннее. Кроме того, я точно знаю, что переход на объектную СУБД даст выигрыш в производительности.

AI

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

Согласен на все 100. Ресурс увеличения производительности за счет железа СИЛЬНО ограничен, и на него нельзя закладываться.
А учет особенностей Оракла - забота тех, кто реализует JDO. Если я использую ООСУБД, то все особенности учтены в концепции стандарта.
17 дек 04, 17:05    [1190006]     Ответить | Цитировать Сообщить модератору
 Re: ООСУБД быстрее ЛЮБЫХ решений с реляционными системами ?  [new]
www.fun4me.narod.ru
Member

Откуда: Moscow
Сообщений: 2406
>> Ведь в случае ООСУБД все контракты конкретного абонента

И кому он нужен - никому неизвестный конкретный абонент, когда в базе их сотни тысяч? Чем он отличается от других таких же и как его искать?


И кто такая Сара
И где она живёт?
А вдруг она не курит?
А вдруг она не пьёт?


А если мне контракты абонента ненужны - зачем мне их грузить тогда из базы? А не грузить нельзя, получается, ведь объект - это то, что существует вне нас, не зависит от нас, внешний мир.
17 дек 04, 17:11    [1190031]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить