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

Откуда: Симферополь
Сообщений: 4045
автор
Я не против )) Я говорю, что SP инкапсулируют стуктуру БД. и на уровне клиента adhoc не нужен. В этом случае тезис превосходства РМД над ОМД в плане adhoc становится более слабым.


adhoc нужен чтобы эти самые SP написать и при этом не менять схему БД. А инкапсуляция - она только изолирует разные части системы друг от друга и к произвольным запросам отношения не имеет
14 июл 05, 17:52    [1705620]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

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

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

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

shuklin

Я говорю, что SP инкапсулируют стуктуру БД. и на уровне клиента adhoc не нужен.

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


shuklin

И ваш пример только доказал истинность данного тезиса. Вы тоже используете инкапсуляцию.

Я использую то, что РМД вся в БД. В проетах на клинте для конечного юзера не используем SQL. С утерей свойст РМД не связываем (она вся в БД). Во многих ситуациях использую SQL итерактивно. И в ходе эксплуатации. В этих клиентах наверняка SQL в клиентах. Это обеспечивает реализацию итерактивности. Важного преимущества SQL.
Но ООСУБД не позволяет так "инкапсулировать" - выносит ОЦ из БД, как тут говорили представители или представитель версанта. Т.е. у РМД с инкапсуляций дела похоже лучше обстоят. И вопрос о ненужности adhoc ей ставить не надо, потому что для нее это не вопрос. В РМД adhoc просто используется.
Но в ООСУБД он не нужен? Вы уверены? Думаете, если бы он там был, то Вы бы этому не радолвались? Как я теперь, када Вы напомнили мне, что, то к чему я привык и считал обычным делом, на самом деле важное достижение, тех кто создали РМД и реализовали РСУБД.
14 июл 05, 19:06    [1705958]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
funikovyuri
автор
Я не против )) Я говорю, что SP инкапсулируют стуктуру БД. и на уровне клиента adhoc не нужен. В этом случае тезис превосходства РМД над ОМД в плане adhoc становится более слабым.


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


Если мы говорим про SP то это уже не adhoc!!!! SP пишутся программерами!
Один раз! В принципиальном отношении по сравнению с декларативным программированием в SP нет ничего качественно нового.
14 июл 05, 20:36    [1706100]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

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

Т.е. Вы думаете, что признаком РМД является отсутствие на клиенте SQL?

Где я такое писал? )) Я писал что признаком ненужности adhoc является отсутствие на клиенте SQL запросов а-ля SELECT|INSERT|UPDATE

vadiminfo

Одним из основным достоинстоинств РМД и заключается независмость от клиентского приложения и наоборот, именно от того, что МД а БД.
Однако присутствие на клиенте вообще, возможности выполнять SQL в интерактивном режиме осталась. При это не всегда и нужно на нем выполнять SQL.

Вот и я говорю - не всегда нужно. ч.т.д. УРА! )))

vadiminfo

Но в ООСУБД он не нужен? Вы уверены?


Я уверен что для ООСУБД adhoc полезен и нужен. Тезис заключается в другом. В мире РБД наметилась тенденция в отказе от adhoc.
14 июл 05, 20:45    [1706107]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
shuklin

Вы как-то интересно понимаете произвольные запросы... Произвольные - это не значит что их конечные пользователи будут писать - это значит, лишь, что имея схему БД можно написать запрос, о котором не знали разработчики этой схемы. Ну и сомо собой этот запрос можно запихнуть в хранимую процедуру
14 июл 05, 22:38    [1706197]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

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

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


В таком случае, этот тезис качественно не отличается от "произвольный алгоритм обхода графа - это не значит, что его пользователи будут писать - это значит, лишь, что имея схему графа ООБД можно написать алгоритм обхода этого графа (никто не запрещает при этом использовать OQL или XPath), о котором не знали разработчики схемы этого графа. Ну само собой, этот алгоритм можно написать на C# и скомпилить в DLL".

PS. Устоявшегося термина "схема графа" имхо еще нет. Я бы предпочел - паттерн нейронного ансамбля (в случае СНС).
14 июл 05, 23:25    [1706216]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

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

Я писал что признаком ненужности adhoc является отсутствие на клиенте SQL запросов а-ля SELECT|INSERT|UPDATE

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

shuklin

Вот и я говорю - не всегда нужно. ч.т.д. УРА! )))

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

shuklin

В мире РБД наметилась тенденция в отказе от adhoc.

Это может быть тока если все возможные запросы, какие тока могут быть в данной ПО предвидели, и потратили на это бабки, что все их найти и написать, предвидя динамику информационных потребностей. Возможно, стабилизация и застой в конкретных ПО может снизить вероятность adhoc. А так врядли, кто-то откажется.
Зачем? Полно всяких генераторов отчетов.
Что-то мир РБД Вы увидели как-то странно. Все СУБД наоборот поступают. Тока наращивают выразительность SQL, чтобы как можно более сложные adhoc можно было как можно быстрей налабать.
15 июл 05, 00:14    [1706235]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
shuklin

Можно конечно, только проблемы с adhoc в ООБД выросла не отсюда... Видете-ли, некоторые :), с инкапсуляцией вместе их связать не могли...
15 июл 05, 12:58    [1707716]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
впрочем, я тоже думаю что это они поспешили
15 июл 05, 12:59    [1707718]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Sarin
Будущее ОРСУБД и ООСУБД
Расскажите.


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

С уважением, Дмитрий.

PS. На данный момент я разрабатываю СООБЗ Cerebrum. Текущую версию можно скачать по адресу http://contest2005.gotdotnet.ru/Request/Tools/UtilitiesLib/163171.aspx. Если кто то имеет какието проблемы, коментарии или пожелания по поводу моей разработки - большая просьба сообщать мне об этом любым удобным способом.
15 июл 05, 13:35    [1707986]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
женщина-программистка
Guest
Как вы думаете, является ли поддержка целостности данных ключевой функцией субд, и если нет, то для чего предназначена такая субд?
15 июл 05, 15:35    [1708938]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
женщина-программистка
Как вы думаете, является ли поддержка целостности данных ключевой функцией субд, и если нет, то для чего предназначена такая субд?


Я думаю, что отсутствие такой поддержки значительно сокращает область возможного применения СУБД. Тем не менее Cerebrum на данный момент не имеет никаких автоматических средств по поддержке целостности данных. Это забота программиста. В будущем такие средства могут быть реализованы на более высоких уровнях. На уровне VNPI реализация данной возможности маловероятна. Дело в том, что в Cerebrum несколько разных экземпляров объектов могут иметь один и тот же OID. Поэтому в общем случае может быть невозможно определить тот handle space в котором должен находится PK для текущего значения - таких handle space может быть несколько. Дальше, в системе ООБД (надстройка над VNPI) поддерживается создание отсутствующих аттрибутов (объектов) on demand. Поэтому отсутствие объекта с некоторым OID не является причиной в отказе создания ссылки с этим OID.

Я уже писал, что Cerebrum преднозначен в первую очередь для моделирования нейронных сетей, семантических сетей, активных семантических сетей, иерархических семантических сетей и сетей фреймов. В узлах этих сетей можно разместить экземпляры собственных классов реализованные на языке C#.

На данный момент, в качестве примера применения СООБЗ Cerebrum разработана продукционная экспертная система. Я предполагаю, что такую ООБД можно использовать в различных CAD|CAM приложениях.
15 июл 05, 16:51    [1709504]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
funikovyuri
Member

Откуда: Симферополь
Сообщений: 4045
женщина-программистка

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

безусловно
15 июл 05, 17:06    [1709625]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
женщина-программистка
Guest
Когда я, например, говорю о хранимых в субд данных, то я имею ввиду структурированнные данные (т.е пользователь видит их как отдельные свойства сущностей, а не как общее memo, blob и т. п) и статичные в некоторой степени (пользователь подтвердил их сохранение после того как наигрался с ними в оперативке))
СУБД должна уметь гарантировать их целостность. Если, например, Cerebrum этого не умеет и у нее нет мат модели для этого, зачем тогда ее сравнивать с РСУБД.

[Я уже писал, что Cerebrum предназначена в первую очередь для моделирования нейронных сетей]
Это предметная область, но интересно, что она хранит для такого класса задач? Содержимое объектов, живущих сейчас, или blob-поля, или то и другое?
15 июл 05, 17:47    [1709879]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

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

Здесь возникает первое отличие от РБД - нет разницы между оперативкой и БД. Чтобы обеспечить отмену сохранения необходимо разработать развитую систему версионинга объектов. Этот этап как раз в процессе. Поэтому я считаю что Cerebrum не поддерживает транзакций (несмотря на то что можно пнуть метод Rollback у объекта NativeDomain и отменить все последние изменения).

Структура у объекта разумеется есть. Все объекты рекомендуется хранить в разобранном на скаляры виде. Поддерживаются деревья объектов. Объект может содержать аттрибуты, являющиеся сложными объектами, у которых тоже есть аттрибуты-объекты ... на любую глубину (до 2млрд простых объектов на одну бд).

женщина-программистка
СУБД должна уметь гарантировать их целостность. Если, например, Cerebrum этого не умеет и у нее нет мат модели для этого, зачем тогда ее сравнивать с РСУБД.

Уже не раз здесь писал что уровень VNPI представляет собой граф с раскрашенными однонаправленными связями.

женщина-программистка
[Я уже писал, что Cerebrum предназначена в первую очередь для моделирования нейронных сетей]
Это предметная область, но интересно, что она хранит для такого класса задач? Содержимое объектов, живущих сейчас, или blob-поля, или то и другое?


И то и другое - по желанию программиста, реализующего объект.
У объекта могут быть аттрибуты. Аттрибуты могут быть: объектами, скалярными значениями, коллекциями OID. Если аттрибут объекта является объектом, то у него тоже могут быть аттрибуты вышеперечисленных типов.

Целостность данных в пределах одного дерева поддерживается автоматически. Целостность FOREIGN KEY между разными ветками деревьев должна обеспечиваться прикладным программистом. Учитывая что основым достоинством ООБД является прямая навигация между разными объектами, то опять же мой старый тезис, что в данной версии целостность не поддерживается остается в силе. Так как можно создать объект в аттрибуте которого будет находится OID несуществующего объекта.
15 июл 05, 19:23    [1710077]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
женщина-программистка

Если, например, Cerebrum этого не умеет и у нее нет мат модели для этого, зачем тогда ее сравнивать с РСУБД.

Тут есть парни, у которых не тока этого, но и многого другого нет, например, дореляционная ОМД. Вообще ничего нет, кроме "хорошо" спроектированных приложений. Но и они видят смысл сравнивать себя с РСУБД. А с чем еще? С иерархическими? Так тада выясняется, что они и доиерархические. А зачем им это надо? Лучше все-таки быть дореляционными, чем доиерархическими.
15 июл 05, 19:58    [1710120]     Ответить | Цитировать Сообщить модератору
 Re: Tapestry  [new]
vybegallo
Guest
Dimonana
В чем суть объектного подхода -
1. наследование
2. инкапсуляция
3. полиморфизм

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

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

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

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

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

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

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

Если Оракл и Ко увидят, что это востребовано, и что именно востребовано, выпустить Oracle 11h с полной поддержкой Объектной Реляционности и соответственно - EJB 3.0, может оказаться не такой уж сложной задачей


И наследование, и полиморфизм есть у Информикса начиная с 9 версии, год примерно 1997. Только оказалось, что никому оно нахрен не надо - это я тебе, голуба, говорю как бывший работник ихнего саппорта.
15 июл 05, 21:03    [1710194]     Ответить | Цитировать Сообщить модератору
 Re: Tapestry  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vybegallo
И наследование, и полиморфизм есть у Информикса начиная с 9 версии, год примерно 1997. Только оказалось, что никому оно нахрен не надо - это я тебе, голуба, говорю как бывший работник ихнего саппорта.

У них наследование таблиц или настоящих объектов? Если настоящих (ни чем не хуже объектов С++) то имхо отдел рекламы у Информикса хреновый. В С++ всем оно надо... а если добавить еще и персистентность - то уже не надо. Так получается? А вот если таблиц, или чегото таблице-подобного, тогда да. Толку от такого наследования, если всеравно второй объект придется на C++ ваять и custom serialization в него делать. И автоматизация этого дела не поможет. Методы то объектов-сервера так и останутся в объекте на сервере, а приложение будет работать с клоном объекта на клиенте. Врядли они сделалют маршаллинг вызовов прокси сервеного объекта (аналог Remoting в .NET) Единственный выход - полноценный ОО язык программирования на стороне сервера. .NET предоставляет фраймеворк для таких языков, Cerebrum предоставляет среду для persistent объектов. Кстати, если кому очень надо, можно Cerebrum под Remoting в клиент-серверном сценарии запускать, но это уже достоинство Microsoft .NET
15 июл 05, 21:20    [1710208]     Ответить | Цитировать Сообщить модератору
 Re: Tapestry  [new]
Dimonische
Member

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

И наследование, и полиморфизм есть у Информикса начиная с 9 версии, год примерно 1997. Только оказалось, что никому оно нахрен не надо - это я тебе, голуба, говорю как бывший работник ихнего саппорта.


Друх, значит нет нормальной интеграции с Ява/с++. Значит OQL нет. Может еще чего нет. Ответь на все мои пункты поподробнее.
15 июл 05, 23:10    [1710310]     Ответить | Цитировать Сообщить модератору
 Re: Tapestry  [new]
vubegallo
Guest
shuklin
vybegallo
И наследование, и полиморфизм есть у Информикса начиная с 9 версии, год примерно 1997. Только оказалось, что никому оно нахрен не надо - это я тебе, голуба, говорю как бывший работник ихнего саппорта.

У них наследование таблиц или настоящих объектов? Если настоящих (ни чем не хуже объектов С++) то имхо отдел рекламы у Информикса хреновый. В С++ всем оно надо... а если добавить еще и персистентность - то уже не надо. Так получается? А вот если таблиц, или чегото таблице-подобного, тогда да. Толку от такого наследования, если всеравно второй объект придется на C++ ваять и custom serialization в него делать. И автоматизация этого дела не поможет. Методы то объектов-сервера так и останутся в объекте на сервере, а приложение будет работать с клоном объекта на клиенте. Врядли они сделалют маршаллинг вызовов прокси сервеного объекта (аналог Remoting в .NET) Единственный выход - полноценный ОО язык программирования на стороне сервера. .NET предоставляет фраймеворк для таких языков, Cerebrum предоставляет среду для persistent объектов. Кстати, если кому очень надо, можно Cerebrum под Remoting в клиент-серверном сценарии запускать, но это уже достоинство Microsoft .NET


наследование таблиц, естественно. Поскольку в БД ценность представляют именно Д в чистом виде, а не Д с присохшей к ним бумаж.. оберткой в виде методов С++/C#/Java/ObjectPascal/Perl 5/... и (каждый язык - со своей версией). То, что вы хотите, называется object persistence framework - их последнее время расплодилось дофига, некоторые по отзывам весьма неплохи, (Hibernate). Но с точки зрения разработчика хранилища данных - ему объекты даром не нужны, его интересуют всякие кубы и adhoc запросы.
16 июл 05, 01:42    [1710374]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
vybegallo
Guest
Кстати, как вы себе представляете хранение объектов С++ на сервере ? Ладно там Java и C# с псевдокодом, но что случится с объектами С++ если вы, не дай бог, задумаете мигрировать с NT 32bit на AIX 64bit ? А код, написанный под десяток юниксов, видеть не доводилось ? там ifdef на ifdef-e сидит и defin-ом погоняет... не, пока не придуман (и стандартизован наподобие SQL) язык описания объектов - это все несерьезно.
16 июл 05, 01:49    [1710377]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
c127
Guest
shuklin

Здесь возникает первое отличие от РБД - нет разницы между оперативкой и БД.


Где Вы ухитряетесь вычитывать такие перлы? Или сами придумываете? ОСНОВНОЕ ПОЛОЖЕНИЕ РСУБД это абстрагирование от способа храниения данных, с этого все начиналось, т.е. система должна скрывать (и все современные СКЛ сервера это успешно делают) от программиста где физически и каким образом лежат данные, т.е. разницы между оперативкой и БД нет и быть не может, иначе это не РСУБД.
16 июл 05, 03:03    [1710403]     Ответить | Цитировать Сообщить модератору
 Re: Tapestry  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vubegallo
наследование таблиц, естественно. Поскольку в БД ценность представляют именно Д в чистом виде, а не Д с присохшей к ним бумаж.. оберткой в виде методов С++/C#/Java/ObjectPascal/Perl 5/... и (каждый язык - со своей версией). То, что вы хотите, называется object persistence framework - их последнее время расплодилось дофига, некоторые по отзывам весьма неплохи, (Hibernate). Но с точки зрения разработчика хранилища данных - ему объекты даром не нужны, его интересуют всякие кубы и adhoc запросы.


Вот в этом то и проблема. Мне как пользователю ОБД нужны методы которые присохли. А без присохшей бумажки мне оно нафиг не надо, врочем именно ты это уже написал. Мало того, методы к таблицам, или сериализация графа объектов в таблицы, мне, опять же нафиг не надо.
16 июл 05, 14:31    [1710714]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
vybegallo
Кстати, как вы себе представляете хранение объектов С++ на сервере ? Ладно там Java и C# с псевдокодом, но что случится с объектами С++ если вы, не дай бог, задумаете мигрировать с NT 32bit на AIX 64bit ? А код, написанный под десяток юниксов, видеть не доводилось ? там ifdef на ifdef-e сидит и defin-ом погоняет... не, пока не придуман (и стандартизован наподобие SQL) язык описания объектов - это все несерьезно.


В очень многих задачах не нужно никуда мигрировать. Windows forever , Unix must die )))))
16 июл 05, 14:32    [1710717]     Ответить | Цитировать Сообщить модератору
 Re: Будущее ОРСУБД и ООСУБД.  [new]
shuklin
Member

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

Здесь возникает первое отличие от РБД - нет разницы между оперативкой и БД.


Где Вы ухитряетесь вычитывать такие перлы? Или сами придумываете? ОСНОВНОЕ ПОЛОЖЕНИЕ РСУБД это абстрагирование от способа храниения данных, с этого все начиналось, т.е. система должна скрывать (и все современные СКЛ сервера это успешно делают) от программиста где физически и каким образом лежат данные, т.е. разницы между оперативкой и БД нет и быть не может, иначе это не РСУБД.


Тьфу на того, кто скажет, что Cerebrum это РСУБД ))) Ващето я это ухитрился сделать а не вычитать. Готовое решение для Microsoft .NET Framework 1.1 доступно в исходниках по адресу http://contest2005.gotdotnet.ru/Request/Tools/UtilitiesLib/163171.aspx

Только не говорите мне, что РСУБД абстрагируют данные от их хранения в памяти приложения. В приложении данные по прежнему храняться в экземплярах классов. А вот ОБД стирает грань между БД и памятью ПРИЛОЖЕНИЯ.
16 июл 05, 14:39    [1710728]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить