Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Иван FXS wrote: > locky > потому как кавалерист это не набор из человека и лошади. > > > - точно! Браво!! Спасибо за помощь!!! > > Может быть в этом и состоит РАЗНИЦА между JOIN в РМД и JOIN в ОО-, что > объекты ТАК ПРОСТО, КАК ЗАПИСИ не "стыкуются", что их - кроме как по > идентификаторам/ключевым_полям - нужно еще (после этого!) и по > "интерфейсам" правильным образом соединить? Видать уж больно я многословен (прадник у меня), поэтому мои мысли теряются в общем шквале речи... Именно это я ранее (или выше, кому как) говорил -- ------------------------- There's no silver bullet! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 17:55 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Иван - оставте их, объекты эти, не надо их джойнить, а то народ ржет пол дня, производительность труда падает! Хотя весело, ничего не скажешь :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 17:56 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Иван FXS locky потому как кавалерист это не набор из человека и лошади. - точно! Браво!! Спасибо за помощь!!! Может быть в этом и состоит РАЗНИЦА между JOIN в РМД и JOIN в ОО-, что объекты ТАК ПРОСТО, КАК ЗАПИСИ не "стыкуются", что их - кроме как по идентификаторам/ключевым_полям - нужно еще (после этого!) и по "интерфейсам" правильным образом соединить? А джойн вообще к объектам применим? У объектов есть отношение "является частью/состоит из", Есть отношение "может быть/является" (программист является человеком, человек может быть программистом), есть связь "делает что-то с чем-то" и тд. А вот отношения "имеет одинаковый атрибут с ... и поэтому с ним сливается в особо извращённой форме" я себе представить немогу Кстати с учётом инкапсуляции кавалерист как раз может быть представлен набором человека , лошади и шашки. А уж как там они друг с другом сношаются никого не волнует - это методы кавалериста доступные только ему и его наследникам. -------------------------------------------------------------------------- В чём отличие Объектного от РМДБ джойна? - в том, наверное, что объекты не так охотно "сливаются", как записи ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:02 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
lockyИменно это я ранее (или выше, кому как) говорил - говорили - и слава богу! Важно то, что JOIN не есть нечто немыслимое! _________________________________________ Только ... Что-то я засомневался ... может я лапшу тут народу вешаю, может в ООБД в "таблице" хранятся не экземпляры объекта (класса), представляемого данной "таблицей", а объекты(классы) различные по функционалу, но имеющие идентичные интерфейсы? А структура (полей) этой "таблицы" - тогда - определяется структурой этого самого интерфейса?7 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:05 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
NaugА вот отношения "имеет одинаковый атрибут с ... и поэтому с ним сливается в особо извращённой форме" я себе представить немогу - эт Вы попали пальцем в ... небо: не "одинаковый атрибут", а одинаковое ЗНАЧЕНИЕ атрибутов, которые ПО СМЫСЛУ являются "стыкуемыми". Смотрите: Кабинет - атрибут номер (конкретно - 542, висит на двери); Сортрудник - имеет допуск в кабинет номер такой-то (конкретно - Петров, 542); - у Петрова нет никакой двери, нет никакого "одинакового атрибута" у сотрудника и кабинета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:17 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
shuklinДопустим таблица = класс. Строка = объект. Колонка = Аттрибут (Property) Значение в колонке для строки - значение поля объекта (Property). Исходя из данной аналогии можно проводить JOIN объектов так же как проводится JOIN строк в таблицах. Однако, свойства классов не эквивалентны свойствам таблиц, свойства строк не эквивалентны свойствам экземпляров и т.д. Несмотря на значительную близость JOIN в РБД и JOIN в ОБД поведение ООБД как целой системы будет заметно отличаться от поведения РБД. Может вы имели ввиду pointer join? Это не аналог обычного join и в системах в которых реализован представляет другую операцию. Что не мешает использовать inner join. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:23 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:42 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Иван FXSможет в ООБД в "таблице" хранятся не экземпляры объекта (класса), представляемого данной "таблицей", а объекты(классы) различные по функционалу, но имеющие идентичные интерфейсы? В Cerebrum - да. Иван FXSА структура (полей) этой "таблицы" - тогда - определяется структурой этого самого интерфейса?7 В Cerebrum - да. Мало того, один и тот же экземпляр некоторого класса может быть строкой нескольких таблиц - случай множественного наследования интерфейса. И просьба, понимать объект в первую очередь как экземпляр класса. Он только выглядит в некоторых ситуациях. У него есть методы, свойства, коллекции указателей на другие объекты и прочее, чего за строкой таблицы так просто не разглядеть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:47 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
GlebZ2 shuklinДопустим таблица = класс. Строка = объект. Колонка = Аттрибут (Property) Значение в колонке для строки - значение поля объекта (Property). Исходя из данной аналогии можно проводить JOIN объектов так же как проводится JOIN строк в таблицах. Однако, свойства классов не эквивалентны свойствам таблиц, свойства строк не эквивалентны свойствам экземпляров и т.д. Несмотря на значительную близость JOIN в РБД и JOIN в ОБД поведение ООБД как целой системы будет заметно отличаться от поведения РБД. Может вы имели ввиду pointer join? Это не аналог обычного join и в системах в которых реализован представляет другую операцию. Что не мешает использовать inner join. Я не знаю такого термина "pointer join" Можете объяснить подробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:49 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Naug А уж как там они друг с другом сношаются никого не волнует - это методы кавалериста доступные только ему и его наследникам. тогда уж ...доступные только ему и их наследникам :) Может начнем по другому: а что является результатом джоина объектов? Таблица их аттрибутов (это я могу представить) или новый объект(вот это мне уже не осилить)? А вообще я думаю в своё время коболовцы так же задорно смеялись над первыми эскуельщиками и приводили не менее убедительные аргументы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 18:54 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
SergSuperМожет начнем по другому: а что является результатом джоина объектов? Таблица их аттрибутов (это я могу представить) или новый объект(вот это мне уже не осилить)? А вот тут как раз мы и натыкаемся на проблему которую обычно называют "невозможностью реализовать представления в ОБД". Как сделать красивее всего я не знаю. На данный момент этот JOIN представляет собой новый объект с заранее заданным ObjectID. Тоесть для того чтобы JOIN произошел необходимо независимо от колличества строк в результирующем курсоре (в терминах РБД) создать столько экземпляров (в ручную) сколько необходимо получить в итоге объектов, являющихся результатом этого JOIN. Фишка тут в том, что такой объект будет совместно владеть аттрибутами других объектов, входящих в объединение и значения этих аттрибутов будут изменятся синхронно для всех экземпляров. Конечно можно предусмотреть автоматическое создание новых экземпляров и сэмитировать поведение VIEW но там возникают недетские проблемы со сборкой мусора в БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 19:06 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
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= ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 19:06 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
автортогда уж ...доступные только ему и их наследникам :) Множественное наследование мастдай(мотивация:его нет в яве, а я больше ниичаво не знаю) - кавалерист как объединение лошади и человека будет не наследовать их методы, а включать в себя переменные типа человек и лошадь к методам которых он и будет обращаться исполняя интерфейс "кентавр". Да даже и с множественным наследованиям - все потомки кавалериста - потомки лошади , но не все потомки лошади - кавалеристы. авторА вообще я думаю в своё время коболовцы так же задорно смеялись над первыми эскуельщиками и приводили не менее убедительные аргументы :) Я обеими руками за объекты , и между ними совершенно точно существуют некие отношения которые наверно можно описать теоретически, но джойны объектов сливающие человека и комнату лишь за то что возраст человека совпадает с номером комнаты - это глюк. Когда же комната ещё приаггригирует себе человеческий атрибут "цвет глаз"... Вообще объект подразумевает под собой не только атрибуты но и методы. А какие могут быть методы у произвольно "слитых" объектов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 19:18 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Не конечно все это прикольно исследовательски проекты CУБЗ. Лошади с всадниками... А почему нельзя хранить объекты как XML и извлекать с помощью XML. Я видел презентацию по DB2 9. Там это можно будет делать.. Типа будет Native XML Storage который будет объединять возможности реляционки и XML Запросы правда не очень понятно выглядят да ничего привыкнем.... Код: plaintext 1. 2. 3. 4. 5. 6. Индексы даже можно будет создавать, какие в задницу СУБЗ когда все обычные реляционки это смогут делать...... Всадников с лошадьми в XML документ запихивать, откуда их можно влюбой язык в объект сериализовать.... Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. Это конечно не претендует на универсальность... Но ближе чем Cereburnы.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 19:30 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Naug Вообще объект подразумевает под собой не только атрибуты но и методы. А какие могут быть методы у произвольно "слитых" объектов. Дык. При сливании объектов в единое целое сливаются только их интерфейсы (в том числе атрибуты как часть интерфейса). Причем интерфейсы могут быть преобразованы (паттерны адаптер, мост и враппер). Реализация не сливается и должна быть продекларирована явно. - как при наследовании интерфейса надо еще его потом реализовать. И произовльно объекты никто не собирается сливать. Они сливаются с учетом FOREIGN KEY (они же pointers в OODB) и заранее заданным алгоритмом (аналог select WHAT where WHERE) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 19:43 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
nkulikovЭто конечно не претендует на универсальность... Но ближе чем Cereburnы.... А потом, когда дерево исчерпает свои возможности перепиливать все наработки на сеть? Нет уш лучше сразу сетевая ООБД А Сerebrum не так уш и далек. Доступен бесплатно для довнлоада уже сегодня. Хотя недоделок там много надо еще исправлять. Ну так это вопрос времени. При текущем темпе эволюционной миграции с РБД через XML в сетевую ОБД я успею за это время десяток ООБД закодить ))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 19:47 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
shuklin А вот тут как раз мы и натыкаемся на проблему которую обычно называют "невозможностью реализовать представления в ОБД". А потому как не надо. В проектирование ООП есть термины абстрагирования от реализации(типа interface). И второе, логический слой. Любую проблему архитектуры можно решить введением логических слоев, кроме проблемы количества логических слоев. Кроме того, если вы почитаете первый манифест, то там есть термин экстент(он не эквивалентен термину экстентов в реализациях РБД). А именно через него реализуется независимость хранения типа. Кстати, по манифесту, в физическом хранении в РБД и ООБД разницы нет. Есть разница в семантике. И на последок, посмотрите языки комега и еще что-то(уже не помню, по моему язык на основе хаскель). А именно joint calculus. Вот это и есть красивое решение. shuklin На данный момент этот JOIN представляет собой новый объект с заранее заданным ObjectID. Тоесть для того чтобы JOIN произошел необходимо независимо от колличества строк в результирующем курсоре (в терминах РБД) создать столько экземпляров (в ручную) сколько необходимо получить в итоге объектов, являющихся результатом этого JOIN. Вы решили получить реляционный результат в объектно-ориентированной базе? В промежуточном этапе на здоровье. В пользовательском результате такого не может быть. Хотя бы потому что БД объектно-ориентирована. shuklin Фишка тут в том, что такой объект будет совместно владеть аттрибутами других объектов, входящих в объединение и значения этих аттрибутов будут изменятся синхронно для всех экземпляров. Конечно можно предусмотреть автоматическое создание новых экземпляров и сэмитировать поведение VIEW но там возникают недетские проблемы со сборкой мусора в БД. Вам следует почитать книжки по архитектуре серверов приложений. В частности консистентность транзакций, и кэширование объектов. Если в первом случае все решено, то с синхронизацией кэша в ORM системах я ни разу не видел решения проблемы. Только во вменяемых OODB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 20:00 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Бесплатно бывает только сыр в мышеловке... Ну-ну... в GemStone который в тысячи раз лучше вашего поделия, и я считаю лучшей ООБД на данный момент времени разрабатывает человек 30, нет многих важных вещей, а уж вам до реальных систем как до луны. И кстати по поводу XML вы мало поняли, это расширение реляционной модели на иерархические данный, работа все равно идет с множествами. У вашего Cereburna нет ничего что в ближайшие лет 5 позволит его использовать в реальных бизнес приложениях. Вы сходите на www.acm.org посмотрите сколько теории написано про журналирование в CУБД, что бы это заработало вам лет 150 потребуется что бы это все написать.... Не стройте илюзий займитесь полезным делом. По поводу объектов... Определение Программы состоят из объектов объекты обмениваются сообщениями, все остальное нужно для удобства програмирования... Здесь нет ни понятия класса, ни понятия интерфейса, ни наследования С этой точки зрения ваша система такая же жесткая как и РСУБД, чего ради огород городить.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 20:11 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
shuklin А потом, когда дерево исчерпает свои возможности перепиливать все наработки на сеть? Нет уш лучше сразу сетевая ООБД А Сerebrum не так уш и далек. Доступен бесплатно для довнлоада уже сегодня. Хотя недоделок там много надо еще исправлять. К сожалению бесплатность для СУБД - далеко не главное преимущество. Для какой-нибудь игрушки может быть. Но для СУБД главное надежность, которая достигается большими трудозатратами на тестирование, я думаю сравнимыми с собственно с разработкой. Одиному человеку это не по силам и даже 6-ым (это для serg99). А ведь еще есть и много других расходов, да и квалификация программистов тоже должна быть мягко говоря очень высокая. В принципе я понимаю, у людей свербит и хочется сделать нечто гениальное, ощасливить человечество, и они не остановятся и будут делать, несмотря на все разумные аргументы - но надо понимать что это нереально. Сделать то может и можно, но это будет именно поделка, которой никто не рискнёт пользоваться в коммерческих целях. Известные то СУБД исчезают с рынка, а уж чтоб пробиться нужны гигантские вложения. nkulikovПо поводу объектов... Определение Программы состоят из объектов объекты обмениваются сообщениями, все остальное нужно для удобства програмирования... Это не определение, а провокация :) Кто-то считает что только он знает как надо работать с данными, Вы считаете что знаете что такое настоящее ООП ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 21:13 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
GlebZ2Есть разница в семантике. И на последок, посмотрите языки комега и еще что-то(уже не помню, по моему язык на основе хаскель). А именно joint calculus. Вот это и есть красивое решение. На Си-омега, Р-шарп, Си-бемоль глядел. Прямых аналогий с теми проблемами которые меня волнуют не углядел. Если не затруднит - ткните меня более конкретно. За joint calculus спасибо. Будем посмотреть. GlebZ2Вы решили получить реляционный результат в объектно-ориентированной базе? В промежуточном этапе на здоровье. В пользовательском результате такого не может быть. Хотя бы потому что БД объектно-ориентирована. Не должно или невозможно? по поводу не должно, так это мне как разработчику решать что должно а что нет. А вот поповоду невозможно - интерестно узнать более подробно почему. GlebZ2Вам следует почитать книжки по архитектуре серверов приложений. В частности консистентность транзакций, и кэширование объектов. Кэширование объектов реализовано. И даже отлажено. На данный момент известных багов нет )) С транзакциями сложнее. Те что есть реализованны в стиле MS-SQL - ROLLBACK рубит все. Меня такое не устраивает. С многопользовательским режимом и мультитред все в зачаточном состоянии. GlebZ2Если в первом случае все решено, то с синхронизацией кэша в ORM системах я ни разу не видел решения проблемы. Только во вменяемых OODB. Как раз с синхронизацией кеша у меня сейчас проблем нет. А вот с транзакциями куча. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 21:54 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
SergSuper К сожалению бесплатность для СУБД - далеко не главное преимущество. Уговорили. Cerebrum переводится в разряд шареваре - кто хочет использовать дожен заплатить сколько не жалко ;) Первым клиентам скидка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.09.2005, 22:02 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
SergSuper Но для СУБД главное надежность, которая достигается большими трудозатратами на тестирование, я думаю сравнимыми с собственно с разработкой. Одиному человеку это не по силам и даже 6-ым (это для serg99). А ведь еще есть и много других расходов, да и квалификация программистов тоже должна быть мягко говоря очень высокая. В общем то для создания прототипа коллектива в 6 человек достаточно. Хотя уже сейчас возникает потребность в тестере, техническом писателе, аналитике и т.п. Насчет надежности согласен, тем не менее объем работ по тестированию определяется в том числе удачностью или наоборот неудачностью основных архитектурных решений. SergSuperВ принципе я понимаю, у людей свербит и хочется сделать нечто гениальное, ощасливить человечество, и они не остановятся и будут делать, несмотря на все разумные аргументы - но надо понимать что это нереально. Сделать то может и можно, но это будет именно поделка, которой никто не рискнёт пользоваться в коммерческих целях. Известные то СУБД исчезают с рынка, а уж чтоб пробиться нужны гигантские вложения. Как пелось в песне "мы рождены что б сказку сделать былью" :-). Все таки интереснее решать серьезные задачи, чем "автоматизировать очередную бухгалтерию". Что касается вложений, то согласен частично. Гигантские вложения нужны если вы хотите войти в мировую пятерку. А так нужны просто "большие вложения" :-). По одному из проектов где я участвовал (он был правда программно-аппаратный, а не чисто программный) были вложены вполне разумные средства и в итоге появились в том числе западные заказчики, которые предпочли разработанное в России изделие, а не аналогичную продукцию ведущих и давно существующих мировых компаний в этой области. И применение самое что ни на есть ответственное. Просто нормальные заказчики прежде чем что то новое применять, основательно это новое тестируют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 00:39 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
IMHO если продукт не поддерживает ACID транзакции то онне имеет права называться СУБД в современном понимании этого термина. Так, объекто-ориентировная библиотека для чтения и записи в файлы. Практическая применимость данной технологии для автоматизации предприятия =0. Даже если предприятие имеет масштаб пивного ларька. ЗЫ Я всегда гоаорил что наш народ любит замутить что-то крутое, и притом абсолютно бесполезное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 01:27 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
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..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 02:17 |
|
||
|
Шуклин на Мембране
|
|||
|---|---|---|---|
|
#18+
Зл0йIMHO если продукт не поддерживает ACID транзакции то онне имеет права называться СУБД в современном понимании этого термина. Так, объекто-ориентировная библиотека для чтения и записи в файлы. Практическая применимость данной технологии для автоматизации предприятия =0. Даже если предприятие имеет масштаб пивного ларька. В целом согласен (кроме ларька). В данном случае транзакции планируется поддерживать, причем более полно чем в Оракл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.09.2005, 03:08 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33257360&tid=1553757]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
1ms |
| others: | 273ms |
| total: | 439ms |

| 0 / 0 |
