Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 74 75 76 77 78 79 [80] 81 82 83   вперед  Ctrl
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
AAron
Member

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


vadiminfo

С ней могли бы работать,например, проги, занимающиеся перекачкой данных в хранилища данных и т.д.


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

Ну я писал. И через консоль они не работали. Был GUI (более-менее нормальный). Так вот историческая информация была очень полезна, т.к. позволяет проводить анализ рынка. А в случае кучи левых объектов, никак не описанных, доступ к которым осуществляется через ж... проводить такой анализ невозможно. Кроме того, как уже было выяснено, у ООСУБД (в том же версанте) очень плохо было с аналитическими возможностями, о чем сообщал AR.
7 апр 05, 16:30    [1449457]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

Откуда:
Сообщений: 137
AAron
А в случае кучи левых объектов, никак не описанных, доступ к которым осуществляется через ж... проводить такой анализ невозможно.


Друх, объясни мне с какого перепоя таблицы оракла с коментами на каждую колонку + нет идиотских сокращений называются "кучей левых объектов"?
7 апр 05, 17:04    [1449656]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

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

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

Например о том, когда будет и где взять такую СУБД, чтобы там и таблицы, и объекты, и методы, и ХП, и триггеры, и чтобы внутри ХП можно было чего-то делать с объектом и там же вызвать методы объекта, которые будут исполняться тут же на сервере и которые повлекут за собой исполнение триггеров без всяких проблем, а так же чтобы с этими объектами можно было работать через обычный sql и т.д. и т.п.

Во!

-- Tygra's --
7 апр 05, 17:14    [1449711]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Почему это принимает, мне это не ясно. Лично я так не считаю.

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

Dimonische

Да забудьте вы про администрирование. 90% процентов прог занимаются не этим.

Да еще забыл, хотя раньше писал Вашему коллеге. Другие СУБД. Т.е. БД может быть распределенной в гетерагенной среде. И к локальным должны выполняться удаленные запросы из других БД. Т.е. другие СУБД могут выступать в качестве клиентских прог.
Да и 10% процентов прог хватит для обоснования этого.
Вот поступило задание внести данные в филиалы заказчика из центрального офиса в массовом порядке. Я пишу запросы SQL и отправляю их админам заказчика, и они запускают на админской проге. Я уже не говорю, что разного рода админских задач много. И не представляю как можно поддерживать БД без спец приложений.
Я, например, вообще не вижу клиентских прог нашей фирмы. Может тока те, что занимаются отчетами.
Конечно, Вы в своем проекте можете найти обоснования обойтись без этого.
Но это больше относится к разделу проектирования. А в этой теме все-таки больше об общих свойствах СУБД речь идет.
7 апр 05, 19:59    [1450292]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
Переформулирую вопрос vadiminfo :
как в ООСУБД (в том же версанте) обстоят дела с репликацией и распределёнными транзакциями?
7 апр 05, 20:17    [1450314]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
p155off
Guest
tygra
Например о том, когда будет и где взять такую СУБД, чтобы там и таблицы, и объекты, и методы, и ХП, и триггеры, и чтобы внутри ХП можно было чего-то делать с объектом и там же вызвать методы объекта, которые будут исполняться тут же на сервере и которые повлекут за собой исполнение триггеров без всяких проблем, а так же чтобы с этими объектами можно было работать через обычный sql и т.д. и т.п.


хранение методов возможно только для управляемых языков (типа C#, Java, Python, Ruby, Smalltalk, ...). Если речь о C++, то сделать хренение методов объектов в БД будет на порядок (а то и на несколько) сложнее. Да и не понятно, будет ли в случае C++ от этого какая-то польза.

например, если ООСУБД предназначается для использования в CAD системах, то от методов объектов в БД пользы может никакой и не быть. Равно как и в случаях, когда ООСУБД используется для накопления больших объемов измерительных данных (хотя не знаю, может здесь от методов какая-то польза и будет). А если ООСУБД предназначена для enterprise-задач, то от помещения части бизнес-логики в методы хранящихся в БД объектов польза может быть существенная.
8 апр 05, 09:47    [1450847]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
p155off

....
например, если ООСУБД предназначается для использования в CAD системах, то от методов объектов в БД пользы может никакой и не быть. Равно как и в случаях, когда ООСУБД используется для накопления больших объемов измерительных данных (хотя не знаю, может здесь от методов какая-то польза и будет). А если ООСУБД предназначена для enterprise-задач, то от помещения части бизнес-логики в методы хранящихся в БД объектов польза может быть существенная.


А зачем для накопления измерительных данных ООСУБД нужна?
8 апр 05, 10:03    [1450897]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Alexey Sh

А зачем для накопления измерительных данных ООСУБД нужна?


Веротно это сильно зависит от специфики задачи, но ООСУБД реально используются в этой сфере и довольно активно. Полагаю, что не последнюю роль здесь играет быстродействие при записи больших объемов хоть как-то структурированных данных.
8 апр 05, 10:12    [1450923]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
хранение методов возможно только для управляемых языков (типа C#, Java, Python, Ruby, Smalltalk, ...). Если речь о C++, то сделать хренение методов объектов в БД будет на порядок (а то и на несколько) сложнее. Да и не понятно, будет ли в случае C++ от этого какая-то польза.

Почему только для управляемых? Зачем бы мне методы на этих языках в БД - чего-то не знаю пока.
Да пусть будут методы даже на том же SQL - он тоже язык, ведь позволяет обходиться только ХП. Но только пусть будет возможность не только писать ХП, а именно метод объекта.
Хотя получается..... Эти методы будут почти что хранимые процедуры... Но с другой стороны, привязанные к конкретному объекту и .... Мда. Нахрена методы вообще нужны? :)) Спрошу чтоли: а чего методы в этих ООСУБД делают? Зачем методы именно на C#, Java и т.д.? Чего такого они делают, чего не может sql? Для сложных рассчетов - ну да, может быть, хотя.... Но систем, где нужно столько сложных рассчетов, маловато будет.

Зачем бы мне нужны были бы объекты с методами (методы внутри СУБД конечно:))?
Ну например есть таблицы клиентов, их заказов, их счета, их настройки... Сделать объект "клиент", в которого затолкать ту же таблицу клиентов.... Ссылку сделать на ... их заказы, счета, настройки.... А смысл? Я и так это все получу - причем более простым способом, чем объектами. Приделать к объекту "клиент" методы - типа getaccountrest, getordersumm.... Ну это у меня и так реализовано в ХП. Небольшая разница получается то.

Дык зачем же мне объекты с методами? Может кто расскажет? А то сомнения берут - а нужно ли это?

-- Tygra's --
8 апр 05, 10:13    [1450930]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

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

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

-- Tygra's --
8 апр 05, 10:16    [1450939]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
Alexey Sh

Переформулирую вопрос vadiminfo :
как в ООСУБД (в том же версанте) обстоят дела с репликацией и распределёнными транзакциями?


Репликация есть всякая разная - навороченная и не очень. Распределенные транзакции в ООСУБД Versant обрабатываются несколько иначе, чем в классических РСУБД - все опять по причине пассивного сервера.

Поясняю. OID (уникальный объектный идентификатор) содержит информацию о том, в какой базе данных находится объект. Это позволяет сохранять сложносвязанные объектные сети в разных БД, не нарушая их целостности. Но контекст транзакции раполагается в приложении, соответственно приложение и управляет взаимодействием между разными БД. Подробнее опишу позднее (сам сначала разберусь).
8 апр 05, 10:29    [1451007]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Sh
Member

Откуда: SPB
Сообщений: 1930
С.Фейерштейн,Б.Прибыл
Oracle PL/SQL для професстоналов
3-е издание, стр 800.

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

....
8 апр 05, 10:35    [1451035]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Alexey Rovdo
Member

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

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


Ну ладно, ладно. Сегодня к вечеру выложу пример в ветке, посвященной продуктам Versant. Банальное заполнение обсуждавшихся там баз тестовыми данными для FastObjects и Oracle.
8 апр 05, 10:41    [1451070]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
ИМХО удобны не просто методы, а полиморфные методы. В потивном случае различия с обычными ...процедурами-функциями никакого.
8 апр 05, 11:10    [1451212]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

А инкапсуляция? Ведь из-за нее они называются методами? А так ведь просто ф-ии.
8 апр 05, 11:29    [1451300]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

Просто файловые системы оказалось трудно сопровождать. А отказ от этого шаг в сторону файловых систем. Там все зависит от приложений.


Ок, я пишу банковскую систему. У нас сейчас взаимодействует (т.е. та область, о которой я хоть что-то знаю) примерно 60 разных модулей со своими базами. Щас глянул - итого 4300 с копейками таблиц. Сейчас взаимодействие между модулями - это XA транзакции на аппсерверах (веблоджик), транзакции примерно на 50% дилегируются Оракловым серверам.

Я осторожно отверждаю, что система только на базах с таблицами была бы сложнее для понимания. Разрабочиков(Java) больше 500, ДВА всего 40.
У нас Оракл/Сайбейз/ДБЮ/ДБ2, есть еще голден сорсы Террадата и еще какие-то мега базы. И даже при такой схеме все равно система слишком сложная. Есть попытки переходить на объектные базы, а для аналитических хреней делать экспорт в ОЛАП инструменты.

Вы уверены, что переведя сотню мегабайт Джава кода в хранимки + хп система будет проще? Я уверен в обратном.


vadiminfo

Я, например, вообще не вижу клиентских прог нашей фирмы. Может тока те, что занимаются отчетами.


О том и речь. А я вижу.

vadiminfo

Конечно, Вы в своем проекте можете найти обоснования обойтись без этого.


ДБА не обходятся, я обхожусь :)
8 апр 05, 11:30    [1451311]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Вы уверены, что переведя сотню мегабайт Джава кода в хранимки + хп система будет проще? Я уверен в обратном.

Почему вы так уверены?
Пусть у нас количество таблиц меньше в 7 раз - это для примера, не совсем точные цифры.
Тогда получается, что у нас должно быть 70 разработчиков на Java и 6 DBA.
Пусть даже уменьшим эти цифры в два раза - 35 и 3.
Но это бред.
Потому что у нас всего 4 разработчика! Которые занимаются и БД и клиентскими приложениями.
Не слишком ли большая разница?
А может потому, что всю работу и логику делает БД?

А все 500 ваших разработчиков занимаются и клиентской частью и бизнес-логикой? Ведь если методы все в клиенте, то логика тоже там. И все разработчики сами добавляют/изменяют методы? И все они получается должны знать всю архитектуру системы? И все они должны каким-то образом поддерживать код в одинаковом состоянии версий?

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

-- Tygra's --
8 апр 05, 11:48    [1451396]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Dimonische
Member

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

А все 500 ваших разработчиков занимаются и клиентской частью и бизнес-логикой? Ведь если методы все в клиенте, то логика тоже там. И все разработчики сами добавляют/изменяют методы? И все они получается должны знать всю архитектуру системы?


Нет, они знают только свой модуль, да и там по сути мало знают. Большинство занимается UI.

tygra

И все они должны каким-то образом поддерживать код в одинаковом состоянии версий?


За состоянием системы следят релиз менеджеры. Их немного.

Такс. Что-то у нас не сходится. С количеством разработчиков.
Помимо базы есть приложения. Они то собственно и пишутся разработчиками. Приложений (грубо - 2 на модуль + 1 административное) - 180 + 20 большин интермодульных - типа ввода и букинья сделок. Итого 200 приклад. Пусть будет примерно по 15 вебстраниц (не включая диалоги) на прикладу - 3000 страниц.

Итого у нас юай 3000 веб страниц. Какой юай у вас?
8 апр 05, 12:01    [1451463]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
автор
Нет, они знают только свой модуль, да и там по сути мало знают. Большинство занимается UI.

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

автор
Такс. Что-то у нас не сходится. С количеством разработчиков.
Помимо базы есть приложения. Они то собственно и пишутся разработчиками. Приложений (грубо - 2 на модуль + 1 административное) - 180 + 20 большин интермодульных - типа ввода и букинья сделок. Итого 200 приклад. Пусть будет примерно по 15 вебстраниц (не включая диалоги) на прикладу - 3000 страниц.

Итого у нас юай 3000 веб страниц. Какой юай у вас?

Ну у нас выделенных модулей нет - один большой.
И ГУИ конечно (Дельфи) - а веб-страницы только для клиентов интернет-магазина :))
Форм приблизительно около 600.
ХП - если только бэкофис взять, то ~2500 (и простых и сложных, это вообще всего столько). На вебе - чуть меньше ХП.

Но если бы логика была в клиентах - не обошлись бы таким малым количеством. Это ведь часто менять много чего нужно - система то всегда в процессе :). И так приходится 1-2 раза в неделю клиентское приложение обновлять (когда формы новые появляются в основном). Но спасает то, что все-же бОльшая часть измнений происходит в БД. Поменял ХП - пожалста, все пользуются уже новой версией, никто и не знает, ни клиент, ни сам юзер, что были изменения, хоть эта ХП внутри логики где-то используется, хоть юзеру список чего-то выдает.

-- Tygra's --
8 апр 05, 12:30    [1451604]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
serg99
Member

Откуда:
Сообщений: 422
tygra
Дык зачем же мне объекты с методами? Может кто расскажет? А то сомнения берут - а нужно ли это?
Не нужно.
8 апр 05, 12:31    [1451606]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Что не нужно - это уже вроде как понятно. :))

Но хочется услышать, почему нужно, от тех, кто так на самом деле думает. И обсудить :) А то как-то не интересно :))

-- Tygra's --
8 апр 05, 12:33    [1451626]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
p155off
Guest
tygra
Что не нужно - это уже вроде как понятно. :))

Но хочется услышать, почему нужно, от тех, кто так на самом деле думает. И обсудить :) А то как-то не интересно :))

-- Tygra's --


Вот хороший пример (правда не мой - вычитал :))

Рассмотрим систему какого-нибудь констр. заведения (работа с чертежами)

Например, пусть есть класс surface_t, который в БД представляется типом:

class surface_t
{
material_t * m_material;
geometry_t m_geometry;
};

Этот класс в программе редактирования чертежей имеет вид:

class surface_t
{
protected :
material_t * m_material;
geometry_t m_geometry;
editor_t * m_editor;
public :
...
// Запросить параметры для редактора (цвет, стиль линии, стиль заливки и т.д.)
void
properties( editor_properties_t & props ) const;

// Изменить значение указанного параметра (цвета, стиля линии и т.д.)
void
change_properties(
const editor_property_t & prop,
editor_undo_redo_t & undo_redo );

// Отобразить объект на чертеже (с учетом группировки, выделения и т.д.)
void
paint(
editor_paint_device_t & device,
editor_selection_t & selection ) const;
};



А в программе печати чертежей:

class surface_t
{
protected :
material_t * m_material;
geometry_t m_geometry;
device_properties_t * m_properties;
public :
...
// Отобразить на указанном устройстве.
void
draw( paint_device_t & device ) const;
...
};

Т.е. это один и тот же класс, который в программах выглядит по разному. Здесь нет никакого множественного наследования. Речь идет о том, что transient-атрибуты и код методов класса в разных программах реализуется разными библиотеками. Здесь нет никаких проблем с порядком инициализации объектов при извлечении из БД. Фокус в том, что разные in-memory представления объекта превращаются в одинаковое представление объекта в БД.

Иными словами, разные отделы (различные клиенты) будут использовать свои методы, которые у них и лежат.
8 апр 05, 13:40    [1452010]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
самопал
Guest
p155off
Вот хороший пример (правда не мой - вычитал :))

Пример - плохой и некорректный!
Немного более корректная версия той же фигни:
struct surface_t // не class !!! нет поведения!
{
   material_t * m_material;
   geometry_t m_geometry;
};

   class editable_object {
   public:
        void   properties( editor_properties_t & props ) const;
        void   change_properties(  const editor_property_t & prop,   editor_undo_redo_t & undo_redo );
        void   paint(   editor_paint_device_t & device,   editor_selection_t & selection ) const;
   }
//    класс в программе редактирования чертежей имеет вид:
   class editable_surface_t : editable_object
   {
   protected :
        struct surface_t surface; // !!!
        editor_t * m_editor;
   public :
        editable_surface(surface_t t_surf, editor_t * t_editor) {....}
        void   properties( editor_properties_t & props ) const;
        void   change_properties(  const editor_property_t & prop,   editor_undo_redo_t & undo_redo );
        void   paint(   editor_paint_device_t & device,   editor_selection_t & selection ) const;
   };
//   А в программе печати чертежей:
   class printable_object {
           void   draw( paint_device_t & device ) const;
   }
   class printable_surface_t: printable_object
   {
   protected :
        struct surface_t surface; // !!!
        device_properties_t * m_properties;
   public :
   ...
   // Отобразить на указанном устройстве.
           void   draw( paint_device_t & device ) const;
   ...
   };
Приношу извинения за ошибки в синтаксисе C++ (давно не юзал), но идея думаю понятна.
8 апр 05, 14:11    [1452219]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
Ну в программе печати используются методы, которые в БД и не нужны - это чисто клентские методы, которые только на клиенте и выполняются.

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

Т.е. я понимаю, что можно сделать и используя объекты. Но смысл то какой? Усложнить организацию данных и способы их вывода и возможность оптимизации? Но зачем? Используя ХП я могу делать все то же самое, только более контролируя процессы.

-- Tygra's --
8 апр 05, 14:14    [1452247]     Ответить | Цитировать Сообщить модератору
 Re: Объектные СУБД от Versant Corporation (FastObjects .NET, FastObjects t7, Developer Su  [new]
Gowest
Guest
tygra
Да и сам объект может быть представлен тремя таблицами - но клиент будет видеть его цельным с помощью ХП, которая выдает данные объекта.


Гон. С помощью ХП можно только получь набор записей, потом опять через отдельные ХП надо звать вложенные коллеции
8 апр 05, 14:23    [1452315]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 74 75 76 77 78 79 [80] 81 82 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить