Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Будущее ОРСУБД и ООСУБД.  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
Расскажите.
7 июл 05, 20:36    [1686192]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
Ясновидящий
Guest
ОРСУБД - остановят своё развитие и загнутся.
ООСУБД - появятся в конце концов.
8 июл 05, 10:00    [1686725]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
Yo!!
Guest
будущее туманно :)
8 июл 05, 10:16    [1686782]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
nik_x
Member

Откуда:
Сообщений: 1887
Ясновидящий
ОРСУБД - остановят своё развитие и загнутся.
ООСУБД - появятся в конце концов.


А когда наступит конец концов?
8 июл 05, 19:28    [1689863]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Да будуще достаточно туманно.
ООСУБД претендовали на революцию, но прошло 15 лет с того пика ожиданий (1989-1991). Ведущие производители не перешли на ООСУБД в начале девяностых, в вместо этого пошли с где-то с 1996 (года примерно - туда сюда пару лет наверное) по пути ОРСУБД - ответ реляционщиков на вызов объектно ориентированных.
Видно, чего-то не хватает. Каких-то новых достижений.
Есть задачи приложений БД, для которых РСУБД не очень хороши, и потому нужно что-то там применять. Но то, что там применяют (ООСУБД) все равно не так хорошо там (на безрыбье типа они там), как хороши РСУБД, где они подходят. А всем теперь надо, чтобы везде было так. Возможно эти достижения толконцут вперед ООСУБД, возможно ОРСУБД, а возможно что-тьо третье. Но када это будет?
Не меньшие ожидания лет 20 тому назад от СУБЗ. Тоже пока все медленно движется, если не стоит на месте. Так что не известно када и что будет.

Сегодня кроме заинтересованных в пропоганде, врядли кто скажет что-то уверенно.
8 июл 05, 19:39    [1689875]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
В ANSI SQL 3 вроде включён стандарт SQL для ОРСУБД.

Сталкивался ли ктонить с применением сабжа в промышленности? Какие сферы сейчас предпочтительны для сабжа? Что такое хранилище данных? Вроде как это - технология завязанная на ОР и ОО СУБД.
8 июл 05, 23:32    [1690212]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Хранилища данных - Data Warehouses делаются на вполне реляционных СУБД, например Oracle, Teradata. Для анализа небольшой объем данных (десятки-сотни тысяч записей) вынают из хранилища (где данных терабайт 10-100). Затем этот "небольшой объем" частенько кидают в многомерный (multidimensional) КУБ. А уж там анализируют - режут (slicing and dicing) по измерениям и смотрят че вышло. Далее чешут репу и с умным видом рисуют тренд. Начальство прется - почти черная магия. Никакого отношения к тупиковой ветви эволюции СУБД под названием "Объектые и Объектно-Реляционные СУБД" эта тезнология не имеет.
12 июл 05, 06:24    [1694745]     Ответить | Цитировать Сообщить модератору
 Tapestry  [new]
Dimonana
Guest
В чем суть объектного подхода -
1. наследование
2. инкапсуляция
3. полиморфизм

Как это ложиться на базы?

1. Наследование - в общем виде выражается в возможности при наличии таблицы Работники создать таблицу Менеджеры, указав что она наследована. Соответственно, появились поля из таблицы Работники.

2. Инкапсуляция (сокрытие реализации) - в базах не нужна абсолютно, именно данные постоянно представляют интерес с разных точек зрения.

3. Полиморфизм - возможность сделать селект по таблице Работники, при этом еще вернуться записи из таблицы Менеджеры.

+ желательно чтобы эта объектность хорошо интегрировалась с ООП языками,
однако оставались независимой от каждого конкретного языка.

+ обязательно сохранить SQL, модифицировав под появивщиеся возможности.

В Яве например, постоянно уточняется что именно нужно, что сохранять объекты ва базу. Сейчас готовится спецификация EJB 3.0 - сохрание объектов, в которой заложены требования N1, N2, N3. Реализация будет выражаться в жестком, хм, сексе разработчиков при переводе объектной структуры в обычную реляционную.

Если Оракл и Ко увидят, что это востребовано, и что именно востребовано, выпустить Oracle 11h с полной поддержкой Объектной Реляционности и соответственно - EJB 3.0, может оказаться не такой уж сложной задачей
12 июл 05, 10:48    [1695207]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
Мимо пробегал...
Guest
ИМХО Вы везде забываете писать ИМХО
12 июл 05, 13:40    [1696185]     Ответить | Цитировать Сообщить модератору
 ООСУБД и ОРСУБД  [new]
Dimonische
Member

Откуда:
Сообщений: 137
Мимо пробегал...
ИМХО Вы везде забываете писать ИМХО


Все что человек говорит, всегда является его скромным мнением, если только он не делает официальный пресс-релиз. Посему бесконечные имхи считаю излишними.
12 июл 05, 16:48    [1697229]     Ответить | Цитировать Сообщить модератору
 Re: Tapestry  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Dimonana
2. Инкапсуляция (сокрытие реализации) - в базах не нужна абсолютно, именно данные постоянно представляют интерес с разных точек зрения.


Интересную я тенденцию наблюаю в последнее время в разработках под MS-SQL. Одним из требований к приложению часто выдвигается - отсутствие plain INSERT, UPDATE & SELECT в программном коде. Работа должна вестись исключительно через SP. Это приводит к инкапсуляции реляционной схемы БД и к полному отсутствию возможности сделать adhoc запрос.

Выходит что промышленность отказалась от свойств РБД которые принято считать сильной сторонй РБД и слабой стороной ОБД ?
12 июл 05, 21:26    [1697997]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

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

Одним из требований к приложению часто выдвигается - отсутствие plain INSERT, UPDATE & SELECT в программном коде. Работа должна вестись исключительно через SP.

Кем это выдвигается? Фамилии у них есть? SP - хранимые процедуры? И в хранимых процедурах запрещается DML? Звучит как новость. Раскройте эту мысль поподробнее, пожалуйста.

shuklin

Это приводит к инкапсуляции реляционной схемы БД и к полному отсутствию возможности сделать adhoc запрос.

Как это инкапсуляция схемы БД? Уточните что имеется в виду.

Вот одним из недостатков ООМД иногда называют нарушение принципа инкапсуляции из-за необходимости оптимизации запросов. Это есть. А вот инкапсуляция схемы БД, это что-то интересненькое, наверное.

shuklin

Выходит что промышленность отказалась от свойств РБД которые принято считать сильной сторонй РБД и слабой стороной ОБД ?

Кто может и отказался, а кто нет. Судя по стандартам, если от чего и отказались так это простоты. Да и то судя в основном по объему, а не содержанию.
12 июл 05, 22:49    [1698084]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
Почему некоторые ораторы считают ОР и ОО СУБД тупиковой ветвью?
13 июл 05, 08:46    [1698391]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Как это бывает обычно, всё будет вообще не так. :)
13 июл 05, 09:59    [1698546]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo

SP - хранимые процедуры? И в хранимых процедурах запрещается DML?


Да, если вы под DML предполагали использование EXEC (@SQL)

vadiminfo

Звучит как новость. Раскройте эту мысль поподробнее, пожалуйста.


Имхо, очень даже правильное требование. Если Дизайн БД хорошо спроектирован, то необходимость в adhoc запросах просто отсутствует.
Так что EXEC (@SQL) не является рекомендованным (в пределах некоторых проектов) так как - требует построения нового плана выполнения, может вызвать проблемы с security если строится на основе строк, передаваемых через параметры SP, и просто не соответсвует единообразию проекта.

Если БД и приложение внедрены и эксплуатируются, то работа с БД ведется исключительно через промежуточный слой SP. Это позволяет относительно лего вносить изменеия в структуру таблиц не вызывая никаких изменений в приложении. Тоесть после некоторой истории эксплуатации системы схема данных предоставляемая SP уже отличается от схемы данных в таблицах.

Тоесть

vadiminfo

shuklin

Это приводит к инкапсуляции реляционной схемы БД и к полному отсутствию возможности сделать adhoc запрос.

Как это инкапсуляция схемы БД? Уточните что имеется в виду.


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


vadiminfo

Вот одним из недостатков ООМД иногда называют нарушение принципа инкапсуляции из-за необходимости оптимизации запросов.

Никто не мешает реализовать в ООСУБД оптимизаторы OQL.
А во многих тривиальных случаях (например получить имя клиента по его ID) прямая навигация и удобнее и понятнее и по крайней мере так же эффективна(а то и эффективнее) чем соединение. В других случаях никто не мешает соединять объекты так же как и в РМД. Причем не только на основе значения полей, но и на основе результатов выполнения их методов (включая полиморфизм).

Так что и по этому тезису ООМД круче РМД ))

vadiminfo

Это есть. А вот инкапсуляция схемы БД, это что-то интересненькое, наверное.


Хм. А для меня это скушные будни ))
13 июл 05, 15:10    [1700489]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
XM
Member

Откуда: ненадолго из запоя
Сообщений: 1264

shuklin wrote:
> Если Дизайн БД хорошо
> спроектирован, то необходимость в adhoc запросах просто отсутствует.

Не, необходимость в adhoc запросах появляется у пользователей с течением
времени и приобретении большего опыта независимо от того, насколько
хорошо спроектирована БД :)

> Если БД и приложение внедрены и эксплуатируются, то работа с БД ведется
> исключительно через промежуточный слой SP. Это позволяет относительно
> лего вносить изменеия в структуру таблиц не вызывая никаких изменений в
> приложении. Тоесть после некоторой истории эксплуатации системы схема
> данных предоставляемая SP уже отличается от схемы данных в таблицах.
По-моему, это достаточно часто используемый метод размещения и выполнения
основного объема бизнес-правил в СУБД.
Вот только не встречал я, чтобы это называлось "инкапсуляция реляционной схемы БД" :)

> Это приводит к инкапсуляции реляционной схемы БД и к полному отсутствию
> возможности сделать adhoc запрос.
Гм, тут я не соглашусь, вряд ли хоть кто-то в здравом уме будет выдвигать
запреты делать adhoc SELECT'ы и проектировать SP так, что такие запросы
будут невозможны :)

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

А вот в ООСУБД результат запроса - не всегда объект ООБД, так что там работа
только с объектами не всегда возможна + есть требования о соответствии
объектов приложения и объектов в ООБД.

Так что РСУБД и по этому тезису покруче будут :)

P.S. shuklin, по-моему Вы несколько некорректно применили [многозначный] термин "инкапсуляция" :)

Posted via ActualForum NNTP Server 1.2

13 июл 05, 15:39    [1700689]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
shuklin
Имхо, очень даже правильное требование. Если Дизайн БД хорошо спроектирован, то необходимость в adhoc запросах просто отсутствует.

«Дизайн БД хорошо спроектирован» -- это сильно сказано:-) А если серьезно, то это утверждение необоснованно. Не знаю, в каких больших проектах вы принимали участие, но говорите вы странные вещи. Качество проектирования БД никак не связано с потребностью в adhoc запросах. Совсем.
shuklin
Так что EXEC (@SQL) не является рекомендованным (в пределах некоторых проектов) так как - требует построения нового плана выполнения, может вызвать проблемы с security если строится на основе строк, передаваемых через параметры SP, и просто не соответсвует единообразию проекта.
Все страньше и страньше. Такое ощущение, что вы говорите о малознакомых вещах. Что ни слово то вопрос. Во-первых, при чем здесь EXEC (@SQL)? Это динамический SQL, а речь шла вообще не об этом. Какие еще проблемы с security? Это все типовые проблемы, решаемые типовым способом. Проблемы эти у тех, кто малоквалифицирован. Единообразию проекта также никак не связано с необходимостью работать только через SP.
shuklin
Если БД и приложение внедрены и эксплуатируются, то работа с БД ведется исключительно через промежуточный слой SP. Это позволяет относительно лего вносить изменеия в структуру таблиц не вызывая никаких изменений в приложении.
А как же view?

Лично моя практика показывает, что для большой системы, построенной поверх БД, наиболее часто меняются вовсе не структура БД, а набор решаемых задач и их алгоритмы. Получается, что наделать хранимок на все случаи жизни нереально.
13 июл 05, 15:56    [1700811]     Ответить | Цитировать Сообщить модератору
 Re: Tapestry  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
shuklin
Dimonana
2. Инкапсуляция (сокрытие реализации) - в базах не нужна абсолютно, именно данные постоянно представляют интерес с разных точек зрения.


Интересную я тенденцию наблюаю в последнее время в разработках под MS-SQL. Одним из требований к приложению часто выдвигается - отсутствие plain INSERT, UPDATE & SELECT в программном коде. Работа должна вестись исключительно через SP. Это приводит к инкапсуляции реляционной схемы БД и к полному отсутствию возможности сделать adhoc запрос.

Выходит что промышленность отказалась от свойств РБД которые принято считать сильной сторонй РБД и слабой стороной ОБД ?

Встречал такие решения, авторы мотивировали какими-то особенностями разграничением доступа в MS SQL.
13 июл 05, 16:30    [1701064]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

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

Да, если вы под DML предполагали использование EXEC (@SQL)

EXEC (@SQL) как, я понимаю, это использование внедренного SQL в другие языки, а DML - обыкновенно, собственно подъязык языка БД, обеспечивающий манипулирование данными. Т.е. не предполагал под DML использование EXEC (@SQL) , но предполагал использование SQL вообще.

Так я уточняю SP - это хранимые процедуры, которые выполняет СУБД (их вроде PSM называют) или средний уровень какой-то вне СУБД? Вот Вы пишите далее:
shuklin

промежуточный слой SP



Вы видите потерю преимуществ в отказе от использоваения EXEC (@SQL) в клиентских прилоджениях, поставляемых заказчику? Я не вижу. Более того,
у нас, например, есть система отчетов, позволяющая писать произвольные запросы, но и она сохраняет их на сервере. Т.е. клиет опять вызывает ХП.
Не говроя про другие проги. Это лучше и по трафику и по сопровождению.

Однако, всякие тулсы во всю используют EXEC (@SQL), потому что SQL может использоваться итерактивно, и это имеет значение при разработке.

Т.е. РСУБД в полной мере реализует идею БД - доступ к ней различных прог, различными способами. Просто EXEC (@SQL) полезен в одних случаях, но менее полезен в других. Так есть другие способы.
Не догоняю Вашу идею об утрате чего-то.


shuklin

Это позволяет относительно лего вносить изменеия в структуру таблиц не вызывая никаких изменений в приложении.

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

shuklin


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

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


shuklin

Так что и по этому тезису ООМД круче РМД ))

По этому тезису - имеем один из недостатков - нарушение принципа инкапсуляции. А это уже нарушение принципов ООМД.
Я не говорю, что это убийственные недостаток. Но все-таки. То она ООМД, то не совсем ООМД. Но у РМД такого нет. Это важно.
Что касается навигации, то сами понимаете, что этого не достаточно сегодня.
И заметьте, что навигация всегда внедренна как язык БД. Типа Exec. Тем более Вы сами говорите, что это сегодня не для промышленных систем, а для других каких-то. Может тока для сельскохозяйственных хорошо подходит.

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

shuklin

Хм. А для меня это скушные будни ))

У всех у нас есть свои скушные будни ))
13 июл 05, 19:53    [1701953]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
XM

Не, необходимость в adhoc запросах появляется у пользователей с течением
времени и приобретении большего опыта независимо от того, насколько
хорошо спроектирована БД :)


Ни разу не встречал оператора, который для составления отчета делает SELECT к БД состоящей из 300 таблиц. Мало того, после года эксплуатации, даже тот же программер, который реализовал эту систему, испытывает значительные затруднения в производстве таких SELECT. Обычно просто меняют туже бизнес-логику в тех же SP. Как ни крути - инкапсуляция и отсутствие adhoc запросов.

Вот где adhoc реально существует - так это в процессе отладки В ООБД для этого можно использовать обычнейший debuger и опять же никто не запрещает реализовать OQL и делать adhoc на нем.

XM

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


А что это если не инкапсуляция? С этой точки зрения набор SP можно рассматривать как интерфейс или как контракт на интерфейс.


XM

Гм, тут я не соглашусь, вряд ли хоть кто-то в здравом уме будет выдвигать
запреты делать adhoc SELECT'ы и проектировать SP так, что такие запросы
будут невозможны :)

Фанатичные запреты - нет конешно. А вот рекомендации - да. Я встречал много проектов в которых adhoc был просто лишним. Думаю, что в 50% остальных, в которых он был, без него можно было легко обойтись.


XM

А вот в ООСУБД результат запроса - не всегда объект ООБД, так что там работа
только с объектами не всегда возможна + есть требования о соответствии
объектов приложения и объектов в ООБД.

Так что РСУБД и по этому тезису покруче будут :)


Если взять для примера СООБЗ Cerebrum (http://contest2005.gotdotnet.ru/Request/Tools/UtilitiesLib/163171.aspx) то результат запроса к таблице (экземпляры классов TableSet, SimpleView, ComponentView ...) действительно не объект управляемый СООБЗ. Однако никто не мешает этому результату быть просто объектом. Я считаю, что системы ООБД должны позволять работать как с персистент объектами так и с экземплярами объектов в RAM. В этом случае результатом запроса к БД является объект в RAM. Так как результат запроса - вещь временная, то OID такой запрос иметь не будет.

Кроме как теоретического неприятия введения дополнительного деления объектов на персистент и темпорари я никаких неудобств у этого подхода не вижу.

+ Если иметь систему сборки мусора объектов в ООБД (в Cerebrum такой системы нет. есть только система сборки мусора в RAM) то можно решить упомянутую проблему более радикально - создавать новые экземпляры персистент объектов on demand при выполнении запроса. Тогда обсуждаемый тезис "А вот в ООСУБД результат запроса - не всегда объект ООБД" станет ложным. (Мне не известны практические реализации этой идеи. Если будет возможность - реализую в Cerebrum но позже). Опять же эта фича выглядит на фоне уже реализованных персистент/темпорари объектов просто лишней потерей рессурсов. Тот же результат можно получать гораздо меньшими затратами.
14 июл 05, 12:44    [1703591]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo
Так я уточняю SP - это хранимые процедуры, которые выполняет СУБД

Да

vadiminfo
или средний уровень какой-то вне СУБД?

Нет

vadiminfo
Вы видите потерю преимуществ в отказе от использоваения EXEC (@SQL) в клиентских прилоджениях, поставляемых заказчику? Я не вижу. Более того, ... Это лучше и по трафику и по сопровождению.

Я тоже не вижу. В том то и тезис. adhoc 1 - не нужен. 2 - не используется в реальной жизни

vadiminfo
Не догоняю Вашу идею об утрате чего-то.

А я и не говорю в данном месте что РБД - плохо. Наоборот. Я говорю, что в РБД тоже есть инкапсуляция, как и в ООБД. и так же как и в ООБД adhoc запросы в РБД часто используются не по назначению (и вообще не нужны). В РБД adhoc запросы делать действительно легко, благодаря EXEC(@SQL) а в ООБД это или труднее или вообще невозможно (зависит от конкретной реализации). Однако, adhoc не нужен ни там ни там!

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


Это и есть инкапсуляция. Особенно, если запретить приложению производить новые виды SQL и разрешить это делать только в SP.

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

А по моему это и есть инкапсуляция. И вовсе не нужно шарахаться от ОО термина, если вдруг оказалось что РБД это тоже умеет. Это ведь хорошо, что в РБД инкапсуляция тоже есть )))


shuklin

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


Благодаря этому у РМД тоже есть совсем не реляционные свойства. Поэтому говорить про кошерную чистоту РМД нелзя уже давно ))
14 июл 05, 13:19    [1703801]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

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

Да
...
Нет

Тада не понял Вашу мысль совсем. Какая разница как ХП выполняют SQL?
Все SQL на сервере. Более того, я Вам писал, а Вы не обратили внимание, что можно создавать adhoc, помещать на сервере и опять их будет выполнять ХП.
На что влияет синтаксис ХП кроме самого ХП, или модуля БД?

shuklin

Я тоже не вижу. В том то и тезис. adhoc 1 - не нужен. 2 - не используется в реальной жизни

Этот ответ был про то, что EXEC (@SQL) все таки выполняентся на клиенте поставляемом клиенту. На клиентьах же вообще, тем более всяких тулсов, админских, разработческих и прочих, он не так и плох. Нам же не всегда нужно запросы в БД запихивать.

С чего Вы взяли, что adhoc не нужен, если главная цель иметь возможность как можно легче и быстрей получить необходимую инфу?
Думаю, что нужен. У нас вообще система, например, предаставляет юзерам стряпать свои отчеты если хотят. Но они хранят их в БД - нет EXEC (@SQL), хотя это adhoc. Зависимости adhoc -> нет в общем случае.
Это я повторил, потому что Вы не ответили на это.
Када я разрабатываю сам SQL - все есть adhoc, но EXEC (@SQL) в тулсе мне лучше.
Еще как используется. При разработке все adhoc, да и сопровождении.
Неужели Вы хотели сказать - этого нет в ООМД, этого не надо?

shuklin

Это и есть инкапсуляция. Особенно, если запретить приложению производить новые виды SQL и разрешить это делать только в SP.

Так я понял, что EXEC (@SQL) плохо в SP (которые в SP) в промышленных? Или все-таки в некоторых клиентских прогах? Где?
Запрещять совсем не надо. Есть када надо, есть када нет. См. выше. Дело проектировщика.

shuklin

И вовсе не нужно шарахаться от ОО термина, если вдруг оказалось что РБД это тоже умеет. Это ведь хорошо, что в РБД инкапсуляция тоже есть )))

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

shuklin

Благодаря этому у РМД тоже есть совсем не реляционные свойства. Поэтому говорить про кошерную чистоту РМД нелзя уже давно ))

Есть обязательные требования, нарушение, которых можно рассмвтривать как нарушение принципов основополагающих РМД, ООМД. А есть расширения, дополнения в соответсвующих СУБД. Вот нарушение инкапсуляции считают таковым. А использование в РСУБД ХП языков третьего поколения нет.
Более того, Оракл поддерживает коллекции как объекты БД. Но они тоже используются как типы столбцов в таблах. Это все расширенные РМД. Вот если бы коллекции как самоситоятельные структуры БД, вне таблов, тада другое дело.
Я уже не говорю про то, что Оракл называл себя ОРСУБД. А появился терми Универсальный сервер.
Я, например, верю, что если ООСУБД и может на что-то расчитывать, тока при каких-то расширениях.
Сегодня, кстати, нет ясной универсальной, общепризнанной ООМД. Но есть основополагающие принципы. Там инкапсуляция конкретно фигурирует.
14 июл 05, 14:22    [1704195]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo

Тада не понял Вашу мысль совсем. Какая разница как ХП выполняют SQL?
Все SQL на сервере.

Разница в том, как формируется SQL. Если клиент никогда не формирует запросов к БД - то имеет место инкапсуляция структуры БД от клиентского приложения. Это в некоторых проектах может значительно облегчить сопровождение. Если в качестве примера взять MS-SQL то MS даже выпустила Microsoft Data Access Application Block который ориентирован в первую очередь на такой сценарий. Клиент не формирует SQL - только вызывает некоторые SP которые являются интерфейсом к БД. Итак мы имеем в итоге эволюции РБД возврат к процедурному стилю программирования )) И это вызвано реалиями а не теориями ))


vadiminfo

Более того, я Вам писал, а Вы не обратили внимание, что можно создавать adhoc, помещать на сервере и опять их будет выполнять ХП.
На что влияет синтаксис ХП кроме самого ХП, или модуля БД?


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

vadiminfo

С чего Вы взяли, что adhoc не нужен, если главная цель иметь возможность как можно легче и быстрей получить необходимую инфу?

Стабильно наблюдаю такую тенденцию.

vadiminfo
Думаю, что нужен. У нас вообще система, например, предаставляет юзерам стряпать свои отчеты если хотят. Но они хранят их в БД - нет EXEC (@SQL), хотя это adhoc. Зависимости adhoc -> нет в общем случае.
Это я повторил, потому что Вы не ответили на это.

Правильно ли я понял, что в вашей системе динамических отчетов не используется конструкция аналогичная EXEC (@SQL)? Я имею в виду в широком смысле.
14 июл 05, 15:02    [1704476]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

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

Разница в том, как формируется SQL.

Все таки мне кажется Вы имеете в виду где он формируется. Раз не надо чтобы на клиенте.

vadiminfo

Клиент не формирует SQL - только вызывает некоторые SP которые являются интерфейсом к БД.

Хорошо. Раз это именно клиентские проги для оператора.

vadiminfo

Итак мы имеем в итоге эволюции РБД возврат к процедурному стилю программирования )) И это вызвано реалиями а не теориями ))

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

vadiminfo

В данном контексте интересен тезис о тенденции отказа от adhoc. Эта тенденция - реальность по крайней мере в некоторых системах. И продиктовано это имхо необходимостью реализовать инкапсуляцию и контракты к интерфейсам в РБД.

Им не надо они и не используют. Хотя как они разрабатывают. Или получают инфу, которая в БД есть, тока запросы заранее не написаны?

vadiminfo

Правильно ли я понял, что в вашей системе динамических отчетов не используется конструкция аналогичная EXEC (@SQL)? Я имею в виду в широком смысле.

Используется, када надо. Т.е. када запрос не известен на стадии копиляции ХП. Так Вы против EXEC (@SQL) в ХП. Вы меня запутали. Но динамический используется в таких же кончструкциях как и статистический.
Запрос формируется в зависимомти от параметорв клиентских прог, вызывающих ХП с сервера. Т.е. они пишу CALL(Имф процедуры(....))
14 июл 05, 15:49    [1704739]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vadiminfo

Все таки мне кажется Вы имеете в виду где он формируется. Раз не надо чтобы на клиенте.

Да. Главное - где. И в данном контексте - чтоб на клиенте никаких "SELECT " + fieldName1 + ...


vadiminfo

Вот если Вы исключите SQL при доступе к данным. А так ничего не изменилось. Он всегда откуда-то вызывался. Просто есть разные интерфейсы.

Важно что на клиенте нет SQL следовательно нет JOIN и следовательно от РМД осалась только МД а "Р" упало и пропало.

vadiminfo

Хотя как они разрабатывают. Или получают инфу, которая в БД есть, тока запросы заранее не написаны?

Разработка это вообще отдельная тема. Меня в данном контексте интересует что пойдет в реальную эксплуатацию.

vadiminfo

Используется, када надо. Т.е. када запрос не известен на стадии копиляции ХП. Так Вы против EXEC (@SQL) в ХП. Вы меня запутали. Но динамический используется в таких же кончструкциях как и статистический.
Запрос формируется в зависимомти от параметорв клиентских прог, вызывающих ХП с сервера. Т.е. они пишу CALL(Имф процедуры(....))


Я не против )) Я говорю, что SP инкапсулируют стуктуру БД. и на уровне клиента adhoc не нужен. В этом случае тезис превосходства РМД над ОМД в плане adhoc становится более слабым. И как следсвие наличие в ОБД adhoc является желательным, но не принципиальным условием. Ну например как наличие возможностей обрабатывать XML в MS-SQL. Удобно, полезно, но вовсе не необходимо. Мало того, наметилась тенденция в отказе от клиентского adhoc и в РБД ))) И ваш пример только доказал истинность данного тезиса. Вы тоже используете инкапсуляцию.
14 июл 05, 17:15    [1705359]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить