Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, eao197, Вы писали:
E>>Если БД не гарантирует надежной фиксации транзакции, то как же ее БД-то называть? GZ>Если подойти буквоедчески, то БД — это просто совокупность объектов. В данном случае, вы наверно хотели сказать СУБД. Но пока мы и не говорили о полноценности решения Serginio1 как современной СУБД и исполнению каких либо стандартов.
Да, действительно, хотел сказать СУБД.
Я просто к тому, что в СУБД надежность хранения очень важный фактор. Не правильно, имхо, откладывать разбирательство с ним на потом. А то может оказаться, что реализованая СУБД показывает супер производительность без защиты от сбоев, а когда такая защита появляется, то:
— либо производительность падает, из-за write-ahead log-а;
— либо дисковое пространство уходит, если измененные страницы записываются в новые файлы данных БД.
А стандарты в области ООСУБД, имхо, вещь труднодостижимая. Не зря же ODMG тихо скончался. Слишком много интертрепаций ООП и подходов к хранению ОО данных. Может быть несколько различных стандартов со временем получатся.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>А результат в 7 секунд был получен на пустой БД или уже на фрагментированной? S> На пустой. Да смысл даже не в этом. Фрагментация роли не играет. Это просто маленький задача эффективного обмена данных сложной иерархии. S> Т.К. XML, Аксессы и прочие локальные Бд были отметены из за медлительности и малопригодности.
О, ситуация проясняется.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[19]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Да, действительно, хотел сказать СУБД.
E>Я просто к тому, что в СУБД надежность хранения очень важный фактор. Не правильно, имхо, откладывать разбирательство с ним на потом. А то может оказаться, что реализованая СУБД показывает супер производительность без защиты от сбоев, а когда такая защита появляется, то: E>- либо производительность падает, из-за write-ahead log-а; E>- либо дисковое пространство уходит, если измененные страницы записываются в новые файлы данных БД.
Не буду флеймить на термин СУБД, это уже будет демагогия. Что касается транзакционного механизма, то вынужден согласится. Он оказывает огромнейшее влияние на архитектуру (и не только для решений БД, но и серверов приложений). Однако TDD и Refactoring здесь тоже рулит. И если автор пойдет по этому пути, с выбросом некоторого кода, то только в путь.
E>А стандарты в области ООСУБД, имхо, вещь труднодостижимая. Не зря же ODMG тихо скончался. Слишком много интертрепаций ООП и подходов к хранению ОО данных. Может быть несколько различных стандартов со временем получатся.
К сожалению, да. Что касается ODMG, то он скорее всего не скончался, а просто выродился обратно в OMG. Не понимаю причин, но к сожалению это факт.
С уважением, Gleb.
Re[12]: Объектно-ориентированные БД: основные принципы, орга
<...> S> Хотя скорости и не оправдали моих надежд (слишком много накладных расходов) но S>по сравнению с 1С это самолет.
S> Хотя пока индексы еще не прикручены и достаточна сырая и полностью не протестированная система но S> вполне работоспособна. Буду рад любым замечаниям, предложением.
Я сходу не очень понял (может у меня к вечеру глаз замылился), а ссылочную целостность нужно самому поддерживать? Например, номер родительской записи в дочерние нужно вручную вставлять?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[12]: Объектно-ориентированные БД: основные принципы, орга
That's good. Только скажи, по каким критериям ты оцениваешь свое решение. Только на высоком уровне. То есть например:
1. Система должна предоставлять быстрый доступ к единичному объекту.
2. Система должна иметь возможность записывать объекты с различной длиной записи.
...
Просто иначе трудно оценить.
С уважением, Gleb.
Re[13]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Я сходу не очень понял (может у меня к вечеру глаз замылился), а ссылочную целостность нужно самому поддерживать? Например, номер родительской записи в дочерние нужно вручную вставлять?
Здесь принцып такой как и в обычном пргограммировании, подчиненной записи не нужно знать своих родителей. Родитель сам до нее доберется.
Если обязательно нужно знать родителя, то в пользовательской структуре это можно и указать.
Цель была отойти от индексов там где они не нужны. В родительской записи есть первая и последняя запись этого достаточно.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[20]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
E>>А стандарты в области ООСУБД, имхо, вещь труднодостижимая. Не зря же ODMG тихо скончался. Слишком много интертрепаций ООП и подходов к хранению ОО данных. Может быть несколько различных стандартов со временем получатся. GZ>К сожалению, да. Что касается ODMG, то он скорее всего не скончался, а просто выродился обратно в OMG. Не понимаю причин, но к сожалению это факт.
ИМХО, причины в том, что ООСУБД на момент принятия ODMG были слишком разными. В POET, например, мне заполнилась работа с ссылками. У них, кажется были четыре режима работы с сылками объекта при выполнении таких операций как загрузка, блокировка и удаление (только сам объект, сам объект и все его ссылки и пара промежуточных вариантов, не помню уже каких). В ODMG этих возможностей не было. Поэтому пользователям POET нужно было решать, либо использовать уникальные возможности POET, но терять портабельность, либо обеспечивать портабильность своих приложений, но отказываться от преимуществ POET. Понятно, что POET Software эта ситуация так же не очень нравилась. Поэтому они и не спешили делать свою СУБД 100% совместимой с ODMG. И у других производителей ООСУБД были, вероятно, схожие мотивы.
А произошло это, имхо, потому, что нет стандарта на ООП (дико звучит, но может быть потом будет понятнее). Вот за SQL стоит математика. Поэтому SQL можно считать всего лишь формой записи объективной реальности -- реляционной алгебры /ох, сейчас опять в неграмотности уличат/. А под ООП можно подсунуть очень широкий диапазон понятий. Ведь нет единого ООП языка. В C++ есть что-то свое (множественное наследование классов), в Java этого нет (есть интерфейсы, но они данных не могут содержать, поэтому для БД могут быть не интересны). В Smalltalk свои заморочки, в других ООП языках свои. И на это все, в самом начале ООП бума, попытались стандарт повесить.
Лично мне не нравилось, что ООСУБД строятся на принципах неявной стабильности. Когда СУБД сама определяет, как и когда объект сохраняется, когда удаляется и т.д. Вот я, когда учился в асспирантуре, пытался построить ООСУБД, которая бы работала на принципах явной стабильности. Была ли она ООСУБД -- почти да (за исключением запросов, но зато с поддержкой миграции данных). По под стандарт ODMG ну ни как бы не вписалась.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[13]: Объектно-ориентированные БД: основные принципы, орга
Обмен данными между конфигурациями различного типа. Данных было очень много, причем поля имели неопределенный тип итд.
И соответственно, быстрый доступ, запись к любого типа объектам.Посмотреть на скорость и тд. Да и некая разминка для пальцев
Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[14]: Объектно-ориентированные БД: основные принципы, орга
<...> S> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
Ох плохо это заканчивается при сопровождении. Особенно когда появляется необходимость поддержки миграции данных (при изменении схемы данных БД). Личный печальный опыт
Именно поэтому производители БД и процветают, что кустари в конце-концов свои разработки забрасывают от безысходности. Или становятся производителями БД
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Объектно-ориентированные БД: основные принципы, орга
S> Обмен данными между конфигурациями различного типа. Данных было очень много, причем поля имели неопределенный тип итд. S> И соответственно, быстрый доступ, запись к любого типа объектам.Посмотреть на скорость и тд. Да и некая разминка для пальцев S> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
Дело в том, что для DTO нормально, но для СУБД — слишком мало и не очень эффективно.
С уважением, Gleb.
Re[15]: Объектно-ориентированные БД: основные принципы, орга
S>> Обмен данными между конфигурациями различного типа. Данных было очень много, причем поля имели неопределенный тип итд. S>> И соответственно, быстрый доступ, запись к любого типа объектам.Посмотреть на скорость и тд. Да и некая разминка для пальцев S>> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД. GZ>Дело в том, что для DTO нормально, но для СУБД — слишком мало и не очень эффективно.
Так я не в коей мере и не претендую этой поделкой претендовать на что либо. Но это отход от РБД, небольшое изыскание, не более того.
А развить если бы и захотел сил нет. Нужен конфигуратор, метаданные,индексы, другой эффективной лабуды механизм транзакций итд.
Но уж сильно меня достал Этот SQL Свет клином на нем сошелся.
А насчет эффективности для конкретной задачи это ты зря.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[15]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
E><...> S>> Просто под конкретную задачу можно сделать свою оптимальную простенькую БД.
E>Ох плохо это заканчивается при сопровождении. Особенно когда появляется необходимость поддержки миграции данных (при изменении схемы данных БД). Личный печальный опыт E>Именно поэтому производители БД и процветают, что кустари в конце-концов свои разработки забрасывают от безысходности. Или становятся производителями БД
Но пример 1С прежде всего убеждает, что главное ООП (псевдо ООП в данном случае) надстройка над любой БД это залог успеха.
Кстати конфигурации весят по 20 МБ, и более половины это програмный текст. Это я камень в огород о 100 000 строк.
У меня только объектное описание одной конфигурации генерится за мегабайт Дельфевого кода. Будущее отнюдь не за СУБД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>А насчет эффективности для конкретной задачи это ты зря.
Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
С уважением, Gleb.
Re[16]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>А произошло это, имхо, потому, что нет стандарта на ООП (дико звучит, но может быть потом будет понятнее). Вот за SQL стоит математика. Поэтому SQL можно считать всего лишь формой записи объективной реальности -- реляционной алгебры /ох, сейчас опять в неграмотности уличат/. А под ООП можно подсунуть очень широкий диапазон понятий. Ведь нет единого ООП языка. В C++ есть что-то свое (множественное наследование классов), в Java этого нет (есть интерфейсы, но они данных не могут содержать, поэтому для БД могут быть не интересны). В Smalltalk свои заморочки, в других ООП языках свои. И на это все, в самом начале ООП бума, попытались стандарт повесить.
+1
E>Лично мне не нравилось, что ООСУБД строятся на принципах неявной стабильности. Когда СУБД сама определяет, как и когда объект сохраняется, когда удаляется и т.д.
Я бы так не сказал. Во многих реализациях — клиент заказывает музыку. В некоторых нет, но там это умеют использовать(как в GemStone). E>Вот я, когда учился в асспирантуре, пытался построить ООСУБД, которая бы работала на принципах явной стабильности. Была ли она ООСУБД -- почти да (за исключением запросов, но зато с поддержкой миграции данных).
Вот-вот. Слишком много продуктов в которых отсутвие запросов объявлялось как не особо нужным. Во главу угла ставился только навигационный доступ. E>По под стандарт ODMG ну ни как бы не вписалась.
Верю. Вот если бы я решил написать OODB в очередной раз(мечтательно), я бы этот стандарт послал бы на ... Реализация OODB слишком привязана к языку на котором она должна работать.
С уважением, Gleb.
Re[22]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
E>>Лично мне не нравилось, что ООСУБД строятся на принципах неявной стабильности. Когда СУБД сама определяет, как и когда объект сохраняется, когда удаляется и т.д. GZ>Я бы так не сказал. Во многих реализациях — клиент заказывает музыку. В некоторых нет, но там это умеют использовать(как в GemStone).
К сожелению, не могут тут ничего добавить. Когда этим плотно занимался не было доступа в Интернет, чтобы получать необходимую информацию. Теперь доступ есть, но нет времени. А то, что знал -- позабыл.
E>>Вот я, когда учился в асспирантуре, пытался построить ООСУБД, которая бы работала на принципах явной стабильности. Была ли она ООСУБД -- почти да (за исключением запросов, но зато с поддержкой миграции данных). GZ>Вот-вот. Слишком много продуктов в которых отсутвие запросов объявлялось как не особо нужным. Во главу угла ставился только навигационный доступ.
Согласен.
Хотя BerkeleyDB показывает, что может быть эффективный поиск, но нет запросов.
E>>По под стандарт ODMG ну ни как бы не вписалась. GZ>Верю. Вот если бы я решил написать OODB в очередной раз(мечтательно), я бы этот стандарт послал бы на ... Реализация OODB слишком привязана к языку на котором она должна работать.
Я так и сделал в очередной раз
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Serginio1, Вы писали:
S>>А насчет эффективности для конкретной задачи это ты зря. GZ>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав?
Глеб я все прекрасно понимаю. Но в 1С я этак лет 8 при чем с дбф. Количество пользователей до 30 (кстати самый многочисленный сегмент). Когда не было терминальных сессий была полная ж.. Файлы летели. Для увеличения скорости на критических по скорости отчетах стоял свой сервер приложений под DCOM на машине с файлами с прямым доступом к файлам в виде настоящих объектов.
При применении терминальных сессий сбоев тфу тфу не было, а востановление сбитых файлов это уже набитя руку оскомина ее не боюсь.
А в ДБФ понятия транзакционности нет как такового.
Ее можно сделать, но мне одному ради интереса ....
Пока больше осматриваюсь. Авось ....
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Serginio1, Вы писали:
E><...> S>>...Будущее отнюдь не за СУБД.
E>Хотелось бы верить, что за ООСУБД, особенно российского производства E>Но, имхо, у SQL еще есть шанс и нас пережить
В таком виде как сейчас навряд ли. Почитал ссылочки Глеба, все они движутся в одном направлении. ХП на манагед языках, объектная надстройка итд. По большому счету глубоко наплевать что за хранилище данных будет использовать сервер приложений. Основная задача это ООП ,быстрая разработка приложений и ее выполнение. Пока это все не ближайшее будущее. А задачи ооочень раветвленные.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Re[17]: Объектно-ориентированные БД: основные принципы, орга
Немного опишу примерный механизм сохранения со страничной адресацией который реализовал когда-то я. Может быть тебе интересно будет. Сразу говорю, что многие детали опущу, терминологию тоже(экстент у меня будет всегда называться страницой).
На каждый тип имеется заголовок, метаданные и список страниц в общем файле. В заголовке соответсвенно лежит информация о первой странице. В странице зарезервировано некоторое служебное пространство для адресации внутренних записей и полей. Записи могут иметь различную длину. Я, например, адресовался с помощью метаданных, приплюсовывая размер оттуда — если число, размер строки брал со страницы. При загруженной странице, пройти список — быстро. Адресация напрямую к записи осуществляется только с помощью специального указателя на индекс из спец. манагера который отвечал за загрузку и выгрузку страниц на диск. . В заголовке, в виде флагов — хранилось степень заполнения страницы — флаг пусто и менее 75%. Реальный размер лежал в служебной информации на самой странице. При добавлении записи, находилась страница в которую можно поместить объект, если таковой не находилось — то создавалась новая страница. В первую очередь, подбирались страницы с флагом менее 75%. При удалении записи — рассчитывалось так, чтобы на странице не оставалось менее 50% свободного пространства. Если меньше, то она распределялась по остальным страницам (сначало проверялись ближние). После сохранения — в заголовке — флаг пустоты страницы. Механизма для удаления страницы из списка — не было. Жалко было тратить время на сохранение соседней страницы — если она была не нужна(была мысль сделать ее в асинхронном процессе).
Эта система очень похожа на систему сохранения MS SQL. Если посмотреть на систему хранения Oracle — то вообще ужаснешся. Там у изменяемый размер экстента.
С уважением, Gleb.
Re[18]: Объектно-ориентированные БД: основные принципы, орга
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, GlebZ, Вы писали:
GZ>>Здравствуйте, Serginio1, Вы писали:
S>>>А насчет эффективности для конкретной задачи это ты зря. GZ>>Извини, если я чем-то обидел, но eao197 прав. Может транзакционный механизм как таковой и не нужен. Но в случае сбоя диска — возможна деструкция файла. А это для БД — смертеподобно. И алгоритм сохранения становится более интересным. Я не прав? S>Глеб я все прекрасно понимаю. Но в 1С я этак лет 8 при чем с дбф. Количество пользователей до 30 (кстати самый многочисленный сегмент). Когда не было терминальных сессий была полная ж.. Файлы летели. Для увеличения скорости на критических по скорости отчетах стоял свой сервер приложений под DCOM на машине с файлами с прямым доступом к файлам в виде настоящих объектов. S> При применении терминальных сессий сбоев тфу тфу не было, а востановление сбитых файлов это уже набитя руку оскомина ее не боюсь. S> А в ДБФ понятия транзакционности нет как такового.
Сочуствую, я как-то обошел программы на dbf (когда-то чего-то непонятное делал на DBASE, в остальном лох). Когда уже начал нормально заниматься базами, сразу попал на транзакционные базы. Каждый человек субъективен, так как судит с высоты своего опыта.
С уважением, Gleb.
PS:Полностью защищенную базу от сбоев построить невозможно. Иначе бы можно было забыть про backup. Но максимально стремится, я думаю следует.
Свет клином на нем сошелся.
