powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Шуклин на Мембране
25 сообщений из 329, страница 8 из 14
Шуклин на Мембране
    #33257230
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Иван FXS wrote:
> locky
> потому как кавалерист это не набор из человека и лошади.
>
>
> - точно! Браво!! Спасибо за помощь!!!
>
> Может быть в этом и состоит РАЗНИЦА между JOIN в РМД и JOIN в ОО-, что
> объекты ТАК ПРОСТО, КАК ЗАПИСИ не "стыкуются", что их - кроме как по
> идентификаторам/ключевым_полям - нужно еще (после этого!) и по
> "интерфейсам" правильным образом соединить?
Видать уж больно я многословен (прадник у меня), поэтому мои мысли
теряются в общем шквале речи... Именно это я ранее (или выше, кому как)
говорил

--
-------------------------
There's no silver bullet!
Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257233
ggv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ggv
Гость
Иван - оставте их, объекты эти, не надо их джойнить, а то народ ржет пол дня, производительность труда падает!
Хотя весело, ничего не скажешь :)
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257246
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Иван FXS locky потому как кавалерист это не набор из человека и лошади.
- точно! Браво!! Спасибо за помощь!!!

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

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

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

--------------------------------------------------------------------------
В чём отличие Объектного от РМДБ джойна?
- в том, наверное, что объекты не так охотно "сливаются", как записи ...
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257252
Иван FXS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lockyИменно это я ранее (или выше, кому как) говорил
- говорили - и слава богу! Важно то, что JOIN не есть нечто немыслимое!
_________________________________________

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

А структура (полей) этой "таблицы" - тогда - определяется структурой этого самого интерфейса?7
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257280
Иван FXS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NaugА вот отношения "имеет одинаковый атрибут с ... и поэтому с ним сливается в особо извращённой форме" я себе представить немогу
- эт Вы попали пальцем в ... небо: не "одинаковый атрибут", а одинаковое ЗНАЧЕНИЕ атрибутов, которые ПО СМЫСЛУ являются "стыкуемыми".

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

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

Может вы имели ввиду pointer join? Это не аналог обычного join и в системах в которых реализован представляет другую операцию. Что не мешает использовать inner join.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257322
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257331
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Иван FXSможет в ООБД в "таблице" хранятся не экземпляры объекта (класса), представляемого данной "таблицей", а объекты(классы) различные по функционалу, но имеющие идентичные интерфейсы?

В Cerebrum - да.

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

В Cerebrum - да.

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

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

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

Я не знаю такого термина "pointer join" Можете объяснить подробнее?
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257343
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naug А уж как там они друг с другом сношаются никого не волнует - это методы кавалериста доступные только ему и его наследникам.
тогда уж ...доступные только ему и их наследникам :)

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

А вообще я думаю в своё время коболовцы так же задорно смеялись над первыми эскуельщиками и приводили не менее убедительные аргументы :)
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257359
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuperМожет начнем по другому: а что является результатом джоина объектов? Таблица их аттрибутов (это я могу представить) или новый объект(вот это мне уже не осилить)?

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

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

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

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

Конечно можно предусмотреть автоматическое создание новых экземпляров и сэмитировать поведение VIEW но там возникают недетские проблемы со сборкой мусора в БД.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257360
GlebZ2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
shuklin
Я не знаю такого термина "pointer join" Можете объяснить подробнее?
Легко
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=
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257371
Naug
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автортогда уж ...доступные только ему и их наследникам :)
Множественное наследование мастдай(мотивация:его нет в яве, а я больше ниичаво не знаю) - кавалерист как объединение лошади и человека будет не наследовать их методы, а включать в себя переменные типа человек и лошадь к методам которых он и будет обращаться исполняя интерфейс "кентавр".

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

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

Вообще объект подразумевает под собой не только атрибуты но и методы. А какие могут быть методы у произвольно "слитых" объектов.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257382
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Не конечно все это прикольно исследовательски проекты CУБЗ.
Лошади с всадниками... А почему нельзя хранить объекты как XML и извлекать с помощью XML. Я видел презентацию по DB2 9. Там это можно будет делать..

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

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

Код: plaintext
1.
2.
3.
4.
5.
6.
for $book in xmlcolumn('BOOKS')/book 
    for $entry in xmlcolumn('REVIEWS')/entry 
    where $book/title = $entry/title 
return <review>
                 {$entry/review/text()}
           </review>;


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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
 
<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ы....
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257397
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naug
Вообще объект подразумевает под собой не только атрибуты но и методы. А какие могут быть методы у произвольно "слитых" объектов.
Дык. При сливании объектов в единое целое сливаются только их интерфейсы (в том числе атрибуты как часть интерфейса). Причем интерфейсы могут быть преобразованы (паттерны адаптер, мост и враппер). Реализация не сливается и должна быть продекларирована явно. - как при наследовании интерфейса надо еще его потом реализовать. И произовльно объекты никто не собирается сливать. Они сливаются с учетом FOREIGN KEY (они же pointers в OODB) и заранее заданным алгоритмом (аналог select WHAT where WHERE)
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257399
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nkulikovЭто конечно не претендует на универсальность... Но ближе чем Cereburnы....

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

А Сerebrum не так уш и далек. Доступен бесплатно для довнлоада уже сегодня. Хотя недоделок там много надо еще исправлять. Ну так это вопрос времени. При текущем темпе эволюционной миграции с РБД через XML в сетевую ОБД я успею за это время десяток ООБД закодить )))
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257412
GlebZ2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
shuklin
А вот тут как раз мы и натыкаемся на проблему которую обычно называют "невозможностью реализовать представления в ОБД".

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

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

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

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

Вам следует почитать книжки по архитектуре серверов приложений. В частности консистентность транзакций, и кэширование объектов. Если в первом случае все решено, то с синхронизацией кэша в ORM системах я ни разу не видел решения проблемы. Только во вменяемых OODB.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257417
nkulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Бесплатно бывает только сыр в мышеловке...

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

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

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

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

Здесь нет ни понятия класса, ни понятия интерфейса, ни наследования
С этой точки зрения ваша система такая же жесткая как и РСУБД, чего ради огород городить....
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257473
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shuklin
А потом, когда дерево исчерпает свои возможности перепиливать все наработки на сеть? Нет уш лучше сразу сетевая ООБД

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


nkulikovПо поводу объектов...
Определение
Программы состоят из объектов объекты обмениваются сообщениями, все остальное нужно для удобства програмирования...
Это не определение, а провокация :)
Кто-то считает что только он знает как надо работать с данными, Вы считаете что знаете что такое настоящее ООП
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257493
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GlebZ2Есть разница в семантике. И на последок, посмотрите языки комега и еще что-то(уже не помню, по моему язык на основе хаскель). А именно joint calculus. Вот это и есть красивое решение.
На Си-омега, Р-шарп, Си-бемоль глядел. Прямых аналогий с теми проблемами которые меня волнуют не углядел. Если не затруднит - ткните меня более конкретно.

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

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

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

GlebZ2Если в первом случае все решено, то с синхронизацией кэша в ORM системах я ни разу не видел решения проблемы. Только во вменяемых OODB.
Как раз с синхронизацией кеша у меня сейчас проблем нет. А вот с транзакциями куча.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257497
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper
К сожалению бесплатность для СУБД - далеко не главное преимущество.

Уговорили. Cerebrum переводится в разряд шареваре - кто хочет использовать дожен заплатить сколько не жалко ;) Первым клиентам скидка.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257563
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SergSuper Но для СУБД главное надежность, которая достигается большими трудозатратами на тестирование, я думаю сравнимыми с собственно с разработкой. Одиному человеку это не по силам и даже 6-ым (это для serg99). А ведь еще есть и много других расходов, да и квалификация программистов тоже должна быть мягко говоря очень высокая.
В общем то для создания прототипа коллектива в 6 человек достаточно. Хотя уже сейчас возникает потребность в тестере, техническом писателе, аналитике и т.п. Насчет надежности согласен, тем не менее объем работ по тестированию определяется в том числе удачностью или наоборот неудачностью основных архитектурных решений.

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

Что касается вложений, то согласен частично. Гигантские вложения нужны если вы хотите войти в мировую пятерку. А так нужны просто "большие вложения" :-). По одному из проектов где я участвовал (он был правда программно-аппаратный, а не чисто программный) были вложены вполне разумные средства и в итоге появились в том числе западные заказчики, которые предпочли разработанное в России изделие, а не аналогичную продукцию ведущих и давно существующих мировых компаний в этой области. И применение самое что ни на есть ответственное. Просто нормальные заказчики прежде чем что то новое применять, основательно это новое тестируют.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257572
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IMHO если продукт не поддерживает ACID транзакции то онне имеет права называться СУБД в современном понимании этого термина. Так, объекто-ориентировная библиотека для чтения и записи в файлы. Практическая применимость данной технологии для автоматизации предприятия =0. Даже если предприятие имеет масштаб пивного ларька.

ЗЫ Я всегда гоаорил что наш народ любит замутить что-то крутое, и притом абсолютно бесполезное.
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257592
Фотография Zhora
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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..."
...
Рейтинг: 0 / 0
Шуклин на Мембране
    #33257593
serg99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зл0йIMHO если продукт не поддерживает ACID транзакции то онне имеет права называться СУБД в современном понимании этого термина. Так, объекто-ориентировная библиотека для чтения и записи в файлы. Практическая применимость данной технологии для автоматизации предприятия =0. Даже если предприятие имеет масштаб пивного ларька.
В целом согласен (кроме ларька). В данном случае транзакции планируется поддерживать, причем более полно чем в Оракл.
...
Рейтинг: 0 / 0
25 сообщений из 329, страница 8 из 14
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Шуклин на Мембране
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]