Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 14   вперед  Ctrl
 Re: Шуклин на Мембране  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Иван FXS wrote:
> locky
> потому как кавалерист это не набор из человека и лошади.
>
>
> - точно! Браво!! Спасибо за помощь!!!
>
> Может быть в этом и состоит РАЗНИЦА между JOIN в РМД и JOIN в ОО-, что
> объекты ТАК ПРОСТО, КАК ЗАПИСИ не "стыкуются", что их - кроме как по
> идентификаторам/ключевым_полям - нужно еще (после этого!) и по
> "интерфейсам" правильным образом соединить?
Видать уж больно я многословен (прадник у меня), поэтому мои мысли
теряются в общем шквале речи... Именно это я ранее (или выше, кому как)
говорил

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

7 сен 05, 17:55    [1856292]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
ggv
Member

Откуда:
Сообщений: 1810
Иван - оставте их, объекты эти, не надо их джойнить, а то народ ржет пол дня, производительность труда падает!
Хотя весело, ничего не скажешь :)
7 сен 05, 17:56    [1856304]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Naug
Member

Откуда:
Сообщений: 663
Иван FXS
locky
потому как кавалерист это не набор из человека и лошади.

- точно! Браво!! Спасибо за помощь!!!

Может быть в этом и состоит РАЗНИЦА между JOIN в РМД и JOIN в ОО-, что объекты ТАК ПРОСТО, КАК ЗАПИСИ не "стыкуются", что их - кроме как по идентификаторам/ключевым_полям - нужно еще (после этого!) и по "интерфейсам" правильным образом соединить?


А джойн вообще к объектам применим? У объектов есть отношение "является частью/состоит из", Есть отношение "может быть/является" (программист является человеком, человек может быть программистом), есть связь "делает что-то с чем-то" и тд. А вот отношения "имеет одинаковый атрибут с ... и поэтому с ним сливается в особо извращённой форме" я себе представить немогу

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

--------------------------------------------------------------------------
В чём отличие Объектного от РМДБ джойна?
- в том, наверное, что объекты не так охотно "сливаются", как записи ...
7 сен 05, 18:02    [1856344]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2368
locky
Именно это я ранее (или выше, кому как) говорил

- говорили - и слава богу! Важно то, что JOIN не есть нечто немыслимое!
_________________________________________

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

А структура (полей) этой "таблицы" - тогда - определяется структурой этого самого интерфейса?7
7 сен 05, 18:05    [1856359]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Иван FXS
Member

Откуда:
Сообщений: 2368
Naug
А вот отношения "имеет одинаковый атрибут с ... и поэтому с ним сливается в особо извращённой форме" я себе представить немогу

- эт Вы попали пальцем в ... небо: не "одинаковый атрибут", а одинаковое ЗНАЧЕНИЕ атрибутов, которые ПО СМЫСЛУ являются "стыкуемыми".

Смотрите:
Кабинет - атрибут номер (конкретно - 542, висит на двери);
Сортрудник - имеет допуск в кабинет номер такой-то (конкретно - Петров, 542);

- у Петрова нет никакой двери, нет никакого "одинакового атрибута" у сотрудника и кабинета.
7 сен 05, 18:17    [1856423]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
GlebZ2
Member

Откуда:
Сообщений: 7
shuklin
Допустим таблица = класс. Строка = объект. Колонка = Аттрибут (Property) Значение в колонке для строки - значение поля объекта (Property). Исходя из данной аналогии можно проводить JOIN объектов так же как проводится JOIN строк в таблицах.
Однако, свойства классов не эквивалентны свойствам таблиц, свойства строк не эквивалентны свойствам экземпляров и т.д. Несмотря на значительную близость JOIN в РБД и JOIN в ОБД поведение ООБД как целой системы будет заметно отличаться от поведения РБД.

Может вы имели ввиду pointer join? Это не аналог обычного join и в системах в которых реализован представляет другую операцию. Что не мешает использовать inner join.
7 сен 05, 18:23    [1856458]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

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

А джойн вообще к объектам применим? У объектов есть отношение "является частью/состоит из", Есть отношение "может быть/является" (программист является человеком, человек может быть программистом), есть связь "делает что-то с чем-то" и тд. А вот отношения "имеет одинаковый атрибут с ... и поэтому с ним сливается в особо извращённой форме" я себе представить немогу


http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx

Описана БД конфигурации СООБЗ Cerebrum. Большинство объектов имеют общими по крайней мере аттрибуты ObjectID, TypeId, Name, Description, DisplayName.

В текущей разработке (результат частично доступен к довнлоаду) находится класс Relation который имеет интерфейс, аналогичный классу Attribute и "с ним сливается в особо извращённой форме" лучше и не скажешь )))

JOIN обектов представляет аггрегацию аттрибутов одного объекта другим объектом. - определение версии 1.
7 сен 05, 18:42    [1856528]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Иван FXS
может в ООБД в "таблице" хранятся не экземпляры объекта (класса), представляемого данной "таблицей", а объекты(классы) различные по функционалу, но имеющие идентичные интерфейсы?


В Cerebrum - да.

Иван FXS
А структура (полей) этой "таблицы" - тогда - определяется структурой этого самого интерфейса?7


В Cerebrum - да.

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

И просьба, понимать объект в первую очередь как экземпляр класса. Он только выглядит в некоторых ситуациях. У него есть методы, свойства, коллекции указателей на другие объекты и прочее, чего за строкой таблицы так просто не разглядеть.
7 сен 05, 18:47    [1856539]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
GlebZ2
shuklin
Допустим таблица = класс. Строка = объект. Колонка = Аттрибут (Property) Значение в колонке для строки - значение поля объекта (Property). Исходя из данной аналогии можно проводить JOIN объектов так же как проводится JOIN строк в таблицах.
Однако, свойства классов не эквивалентны свойствам таблиц, свойства строк не эквивалентны свойствам экземпляров и т.д. Несмотря на значительную близость JOIN в РБД и JOIN в ОБД поведение ООБД как целой системы будет заметно отличаться от поведения РБД.

Может вы имели ввиду pointer join? Это не аналог обычного join и в системах в которых реализован представляет другую операцию. Что не мешает использовать inner join.


Я не знаю такого термина "pointer join" Можете объяснить подробнее?
7 сен 05, 18:49    [1856546]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Naug
А уж как там они друг с другом сношаются никого не волнует - это методы кавалериста доступные только ему и его наследникам.

тогда уж ...доступные только ему и их наследникам :)

Может начнем по другому: а что является результатом джоина объектов? Таблица их аттрибутов (это я могу представить) или новый объект(вот это мне уже не осилить)?

А вообще я думаю в своё время коболовцы так же задорно смеялись над первыми эскуельщиками и приводили не менее убедительные аргументы :)
7 сен 05, 18:54    [1856558]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
SergSuper
Может начнем по другому: а что является результатом джоина объектов? Таблица их аттрибутов (это я могу представить) или новый объект(вот это мне уже не осилить)?


А вот тут как раз мы и натыкаемся на проблему которую обычно называют "невозможностью реализовать представления в ОБД".

Как сделать красивее всего я не знаю.

На данный момент этот JOIN представляет собой новый объект с заранее заданным ObjectID. Тоесть для того чтобы JOIN произошел необходимо независимо от колличества строк в результирующем курсоре (в терминах РБД) создать столько экземпляров (в ручную) сколько необходимо получить в итоге объектов, являющихся результатом этого JOIN.

Фишка тут в том, что такой объект будет совместно владеть аттрибутами других объектов, входящих в объединение и значения этих аттрибутов будут изменятся синхронно для всех экземпляров.

Конечно можно предусмотреть автоматическое создание новых экземпляров и сэмитировать поведение VIEW но там возникают недетские проблемы со сборкой мусора в БД.
7 сен 05, 19:06    [1856583]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
GlebZ2
Member

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

Я не знаю такого термина "pointer join" Можете объяснить подробнее?

Легко
[url=http://]http://www.google.ru/search?hl=ru&q=pointer+join+OODB&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&lr=[/url]
7 сен 05, 19:06    [1856584]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Naug
Member

Откуда:
Сообщений: 663
автор
тогда уж ...доступные только ему и их наследникам :)

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

Да даже и с множественным наследованиям - все потомки кавалериста - потомки лошади , но не все потомки лошади - кавалеристы.

автор
А вообще я думаю в своё время коболовцы так же задорно смеялись над первыми эскуельщиками и приводили не менее убедительные аргументы :)
Я обеими руками за объекты , и между ними совершенно точно существуют некие отношения которые наверно можно описать теоретически,
но джойны объектов сливающие человека и комнату лишь за то что возраст человека совпадает с номером комнаты - это глюк. Когда же комната ещё приаггригирует себе человеческий атрибут "цвет глаз"...

Вообще объект подразумевает под собой не только атрибуты но и методы. А какие могут быть методы у произвольно "слитых" объектов.
7 сен 05, 19:18    [1856606]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
nkulikov
Guest
Не конечно все это прикольно исследовательски проекты CУБЗ.
Лошади с всадниками... А почему нельзя хранить объекты как XML и извлекать с помощью XML. Я видел презентацию по DB2 9. Там это можно будет делать..

Типа будет Native XML Storage который будет объединять возможности реляционки и XML

Запросы правда не очень понятно выглядят да ничего привыкнем....

for $book in xmlcolumn('BOOKS')/book 
    for $entry in xmlcolumn('REVIEWS')/entry 
    where $book/title = $entry/title 
return <review>
                 {$entry/review/text()}
           </review>;


Индексы даже можно будет создавать, какие в задницу СУБЗ когда все обычные реляционки это смогут делать...... Всадников с лошадьми в XML документ запихивать, откуда их можно влюбой язык в объект сериализовать....

 
<dept bldg=101>
    <employee id=901>
           <name>John Doe</name>
<phone>408 555 1212</phone>
<office>344</office>
</employee>
<employee id=902>
<name>Peter Pan</name>
<phone>408 555 9918</phone>
<office>216</office>
</employee>
</dept>

Проиндексировали всех сотрудников по именам....

create index idx3 on dept(deptdoc) generate key
using xmlpattern '/dept/employee/name' atomic as sql varchar(35);




Это конечно не претендует на универсальность... Но ближе чем Cereburnы....
7 сен 05, 19:30    [1856629]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

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

Вообще объект подразумевает под собой не только атрибуты но и методы. А какие могут быть методы у произвольно "слитых" объектов.

Дык. При сливании объектов в единое целое сливаются только их интерфейсы (в том числе атрибуты как часть интерфейса). Причем интерфейсы могут быть преобразованы (паттерны адаптер, мост и враппер). Реализация не сливается и должна быть продекларирована явно. - как при наследовании интерфейса надо еще его потом реализовать. И произовльно объекты никто не собирается сливать. Они сливаются с учетом FOREIGN KEY (они же pointers в OODB) и заранее заданным алгоритмом (аналог select WHAT where WHERE)
7 сен 05, 19:43    [1856658]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
nkulikov
Это конечно не претендует на универсальность... Но ближе чем Cereburnы....


А потом, когда дерево исчерпает свои возможности перепиливать все наработки на сеть? Нет уш лучше сразу сетевая ООБД

А Сerebrum не так уш и далек. Доступен бесплатно для довнлоада уже сегодня. Хотя недоделок там много надо еще исправлять. Ну так это вопрос времени. При текущем темпе эволюционной миграции с РБД через XML в сетевую ОБД я успею за это время десяток ООБД закодить )))
7 сен 05, 19:47    [1856660]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
GlebZ2
Member

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

А вот тут как раз мы и натыкаемся на проблему которую обычно называют "невозможностью реализовать представления в ОБД".

А потому как не надо.
В проектирование ООП есть термины абстрагирования от реализации(типа interface). И второе, логический слой. Любую проблему архитектуры можно решить введением логических слоев, кроме проблемы количества логических слоев. Кроме того, если вы почитаете первый манифест, то там есть термин экстент(он не эквивалентен термину экстентов в реализациях РБД). А именно через него реализуется независимость хранения типа. Кстати, по манифесту, в физическом хранении в РБД и ООБД разницы нет. Есть разница в семантике. И на последок, посмотрите языки комега и еще что-то(уже не помню, по моему язык на основе хаскель). А именно joint calculus. Вот это и есть красивое решение.

shuklin

На данный момент этот JOIN представляет собой новый объект с заранее заданным ObjectID. Тоесть для того чтобы JOIN произошел необходимо независимо от колличества строк в результирующем курсоре (в терминах РБД) создать столько экземпляров (в ручную) сколько необходимо получить в итоге объектов, являющихся результатом этого JOIN.

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

shuklin

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

Вам следует почитать книжки по архитектуре серверов приложений. В частности консистентность транзакций, и кэширование объектов. Если в первом случае все решено, то с синхронизацией кэша в ORM системах я ни разу не видел решения проблемы. Только во вменяемых OODB.
7 сен 05, 20:00    [1856686]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
nkulikov
Guest
Бесплатно бывает только сыр в мышеловке...

Ну-ну... в GemStone который в тысячи раз лучше вашего поделия, и я считаю лучшей ООБД на данный момент времени разрабатывает человек 30, нет многих важных вещей, а уж вам до реальных систем как до луны.

И кстати по поводу XML вы мало поняли, это расширение реляционной модели на иерархические данный, работа все равно идет с множествами.

У вашего Cereburna нет ничего что в ближайшие лет 5 позволит его использовать в
реальных бизнес приложениях. Вы сходите на www.acm.org посмотрите сколько теории написано про журналирование в CУБД, что бы это заработало вам лет 150 потребуется что бы это все написать.... Не стройте илюзий займитесь полезным делом.

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

Здесь нет ни понятия класса, ни понятия интерфейса, ни наследования
С этой точки зрения ваша система такая же жесткая как и РСУБД, чего ради огород городить....
7 сен 05, 20:11    [1856704]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
SergSuper
Member

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

А потом, когда дерево исчерпает свои возможности перепиливать все наработки на сеть? Нет уш лучше сразу сетевая ООБД

А Сerebrum не так уш и далек. Доступен бесплатно для довнлоада уже сегодня. Хотя недоделок там много надо еще исправлять.

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


nkulikov
По поводу объектов...
Определение
Программы состоят из объектов объекты обмениваются сообщениями, все остальное нужно для удобства програмирования...

Это не определение, а провокация :)
Кто-то считает что только он знает как надо работать с данными, Вы считаете что знаете что такое настоящее ООП
7 сен 05, 21:13    [1856807]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
GlebZ2
Есть разница в семантике. И на последок, посмотрите языки комега и еще что-то(уже не помню, по моему язык на основе хаскель). А именно joint calculus. Вот это и есть красивое решение.

На Си-омега, Р-шарп, Си-бемоль глядел. Прямых аналогий с теми проблемами которые меня волнуют не углядел. Если не затруднит - ткните меня более конкретно.

За joint calculus спасибо. Будем посмотреть.

GlebZ2
Вы решили получить реляционный результат в объектно-ориентированной базе? В промежуточном этапе на здоровье. В пользовательском результате такого не может быть. Хотя бы потому что БД объектно-ориентирована.

Не должно или невозможно? по поводу не должно, так это мне как разработчику решать что должно а что нет. А вот поповоду невозможно - интерестно узнать более подробно почему.

GlebZ2
Вам следует почитать книжки по архитектуре серверов приложений. В частности консистентность транзакций, и кэширование объектов.

Кэширование объектов реализовано. И даже отлажено. На данный момент известных багов нет )) С транзакциями сложнее. Те что есть реализованны в стиле MS-SQL - ROLLBACK рубит все. Меня такое не устраивает. С многопользовательским режимом и мультитред все в зачаточном состоянии.

GlebZ2
Если в первом случае все решено, то с синхронизацией кэша в ORM системах я ни разу не видел решения проблемы. Только во вменяемых OODB.

Как раз с синхронизацией кеша у меня сейчас проблем нет. А вот с транзакциями куча.
7 сен 05, 21:54    [1856857]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
shuklin
Member

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

К сожалению бесплатность для СУБД - далеко не главное преимущество.


Уговорили. Cerebrum переводится в разряд шареваре - кто хочет использовать дожен заплатить сколько не жалко ;) Первым клиентам скидка.
7 сен 05, 22:02    [1856864]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
serg99
Member

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

В общем то для создания прототипа коллектива в 6 человек достаточно. Хотя уже сейчас возникает потребность в тестере, техническом писателе, аналитике и т.п. Насчет надежности согласен, тем не менее объем работ по тестированию определяется в том числе удачностью или наоборот неудачностью основных архитектурных решений.

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

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

Что касается вложений, то согласен частично. Гигантские вложения нужны если вы хотите войти в мировую пятерку. А так нужны просто "большие вложения" :-). По одному из проектов где я участвовал (он был правда программно-аппаратный, а не чисто программный) были вложены вполне разумные средства и в итоге появились в том числе западные заказчики, которые предпочли разработанное в России изделие, а не аналогичную продукцию ведущих и давно существующих мировых компаний в этой области. И применение самое что ни на есть ответственное. Просто нормальные заказчики прежде чем что то новое применять, основательно это новое тестируют.
8 сен 05, 00:39    [1856992]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
IMHO если продукт не поддерживает ACID транзакции то онне имеет права называться СУБД в современном понимании этого термина. Так, объекто-ориентировная библиотека для чтения и записи в файлы. Практическая применимость данной технологии для автоматизации предприятия =0. Даже если предприятие имеет масштаб пивного ларька.

ЗЫ Я всегда гоаорил что наш народ любит замутить что-то крутое, и притом абсолютно бесполезное.
8 сен 05, 01:27    [1857013]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
Zhora
Member

Откуда: USA New York
Сообщений: 402
Some exempts from recent J.Celko book "SQL programming style" (pp.66-67):

"...His (Stroustrup's -Zhora) answer was that Bell Labs, with all its talent
had tried four different approaches to this problem (how to put OO stuff into SQL-Zhora) and came to the conclusion that you should not do it. OO was great (?-Zhora) for the programming but deadly for data..."

"... I have watched people try to force OO models into SQL, and it falls apart in about a year. Every typo becomes a new attribute, or class queries that would have been so easy in relational model are now multitable monster outer join, redundancy grows at an exponential rate, constraints are virtually impossible to write so you can kiss data integrity goodbye, and so on..."

"... It took six man-hours (me and one of the OO developers for three hours) to come up with a query that was the equivalent of: select * from field_offices;
The data needed consisted of basic information, name of the office location, address, manager, and phone. The final query was almost a full page long, requiring the joining of all the various tables for each dta element (as each data element is now an object and each object has its own attributes, so requires its own table), and of course the
monster object-linking tables so as to obtain the correct instance of each object..."
8 сен 05, 02:17    [1857037]     Ответить | Цитировать Сообщить модератору
 Re: Шуклин на Мембране  [new]
serg99
Member

Откуда:
Сообщений: 422
Зл0й
IMHO если продукт не поддерживает ACID транзакции то онне имеет права называться СУБД в современном понимании этого термина. Так, объекто-ориентировная библиотека для чтения и записи в файлы. Практическая применимость данной технологии для автоматизации предприятия =0. Даже если предприятие имеет масштаб пивного ларька.
В целом согласен (кроме ларька). В данном случае транзакции планируется поддерживать, причем более полно чем в Оракл.
8 сен 05, 03:08    [1857040]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить