Здравствуйте, Real 3L0, Вы писали:
R3>В чем тогда выражается выделенное? А где в выделенном слово "таблица"?
Оффтоп
Вообще, программирование, как и любая инженерная область, довольно-таки точная дисциплина. Мелкие и несущественные детали формулировок очень сильно меняют смысл. В термины стоит тщательно вдумываться. Пример: объект и класс — совершенно разные вещи. Ламеры могут произвольно менять их местами, настоящие программисты — нет. Второй пример: таблица и база данных. В соответствующий форум еженедельно постятся десятки людей, которые используют эти термины взаимозаменяемо. Настоящие программисты так не делают. Более того, они даже отличают термин "база данных" от термина "система управления базами данных". Освоение правильной терминологии весьма ощутимо помогает улучшить эффективность коммуникации с коллегами.
/Оффтоп
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Real 3L0, Вы писали: R3>Согласен, но после создания некоторой оболочки над БД (фреймворка) всё становится просто. Другой вопрос: объясни мне что такое наследование в понятии ООБД?
Оно имеет тот же самый смысл, что и в обычном ООП. R3>Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД.
Стоит. ООБД оперирует понятиями более высокого порядка, и потому сокращает объем ручной работы. Правда, современные ООБД по большей части вынуждают разработчика потратить сэкономленное время на попытки добиться приемлемой производительности. Но в идеале работа с ООБД будет намного комфортнее, чем с РБД.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Sinclair, Вы писали:
R3>>>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля. R3>>>Я правильно мыслю? S>>Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы.
R3>В чем отличие объектов от классов? Всю жизнь считал что они равны — сначала pascal, потом c++.
Ну хотя бы тем, что объект -- это экземпляр. А класс -- это множество экземпляров объектов.
В некоторых языках класс так же может быть экземпляром, но там речь идет о метаклассах. В C++, например, такого понятия не существует.
R3>Почему же тогда название ООБД?
А почему языки программирования называются объектно-ориентированными? Потому, что они естественным образом поддерживают объектную парадигму. Тоже самое в полной мере относится и к ООБД.
R3>Далее, я другое хотел сказать. Классическая РБД: таблица, в ней строка, строка, строка, ... R3>Тогда по аналогии, ООБД: объект (пусть класс) с переменными, ещё такой же объект, ещё, ... R3>Думаю, никому тут не станет проблемой преобразовать РБД -> ООБД -> РБД.
Может стать. Это зависит от типов атрибутов в объекте. Например, преобразовать такой объект в РБД может быть не так просто и эффективно, как покажется сначала:
class B { ... };
class C { ... };
class D { ... };
class E { ... };
class A
{
std::vector< B > m_vector;
std::map< C, D > m_map;
std::list< E * > m_list;
};
Где под (E*) можно, например, понимать ссылки на объекты типа E в БД.
R3> Но тут мы вводим наследование в ООБД и создаем новый наследуемый объект. И кто мне теперь скажет, как понять где у нас какие переменные?
Тут у тебя какой-то сумбур, сформулируй точнее, что ты хочешь понять.
Например, пусть есть еще один класс:
class I : public E { ... };
Мы создаем его экземпляр в БД и помещаем ссылку на него в A::m_list. Когда мы поднимаем объект типа A из БД автоматически поднимается его атрибут m_list и все объекты типа E (и производных от них типов), ссылки на которые были в m_list. Если в m_list была ссылка на объект типа I, то из БД поднимится именно объект типа I. А как это произойдет -- это уже забота ООБД.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Real 3L0, Вы писали:
R3> R3>Нет, забудем про таблицы. Я имел ввиду, в чем же тогда выражается, что это база данных?
В поддержке определенных свойств. В основном, это:
— устойчивость к сбоям
— многопользовательская работа
— ассоциативный поиск/поддержка декларативного языка запросов
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, GlebZ, Вы писали:
GZ>>1. Эффективный навигационный доступ возможен только при наличии локальной базы.
P>Не понимаю довода. P>Эффективный — это быстрый или мощный?
Да. P>навигационный — это просто Select или курсоры?!
Курсоры. В случае если она расположена удаленно, ты получаешь ворох межпроцессорных вызовов по сетке. P>локальная база — расположена на моем винчестере?
Да
GZ>>2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
P>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД.
Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных.
GZ>>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
P>Насколько я понял, гарантии такие же, как и при использовании РСУБД. Т.е. если РСУБД не упала, всё работает, если упала — ну что тут поделаешь: меняйте провайдера. Транзакций нет.
Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде. Что касается prevalyar я в принципе не смотрел, есть ли возможность откатов транзакций. И возможна ли работа в виде Read Commited?
GZ>>Резюме. GZ>>Это поделка без каких либо вариантов называться серьезной OODB не может. P>Вопрос звучал: правильный ли это подход? Транзакции и изоляцию можно навернуть просто на уровне объектов.
Не получится. Транзакционный механизм является влияющим на всю архитектуру. Особенно в контексте изолированности и concurency. P>Но что насчет подхода?
Это все и был ответ.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, GlebZ, Вы писали:
P>>>Эффективный — это быстрый или мощный? GZ>>Да. P>Что да Оба что ли?
Почему бы и нет.
P>>>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД. GZ>>Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
P>Не верю, что известно. Мне непонятно, откуда может взяться разница.
Ой, знаешь сколько механизмов сделано ради этого. Наличие свободного пространства — чтобы можно было быстро впихнуть значение, порядок объектов — которые не обязательно упорядочены по некоторому значению (в пределах страницы всегда) но всегда упорядочены по типам, и соответсвенно загрузка происходит не одной страницы, а сразу по нескольким если высока вероятность что будут прочитаны объекты с других страниц. Экстенты. и т.д.
Раньше было в порядке вещей делать свои драйвера для диска. Чтобы класть данные именно в таком порядке, чтобы не перебегать головкой диска с дорожки на дорожку. Сейчас (IMХО) подразумевается что система хранит файл БД в дефрагментированном состоянии. А свап по определению внутри сильно дефрагментирован.
GZ>>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных. P>Это так, но дело в том, что РСУБД неэффективно использует место и + хранит много дополнительной информации. Возьмем какую-нибудь процессинговую систему: десять миллионов записей о продажах шириной в 200 колонок должна весить около 16 гигабайт, а что получаем на деле?
Используется оно в том то и дело, очень эффективно. И занимает место для этой цели, действительно больше.
GZ>>Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде. P>Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях.
Ну-ну. А если база данных распределенная? И состояние на других хостах уже изменено?
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Borisman2, Вы писали:
B>>Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
R3>Полностью согласен. Сколько не читал про эти ООБД и ООСУРБД — никто толком даже не смог объяснить, каким боком они собираются всунуть в эти БД наследование в понятии ООП. По моему, народ услышал термин ООП, разобрался в нем и теперь пытается запихать это ООП куда не поподя. Ну почему движок должен быть обязательно встроен в БД? Разве не достаточно какого-нибудь фреймворка над РБД? Мой ответ — вполне.
Не всем подходит твой ответ.
Встречаются такие проекты, где стоимость отображения объектной модели приложения на RDBMS превышает разумные пределы.
Там первое требование — персистить сложную объектную модель в неизменном виде, чтобы потом на ее основе генерировать многочисленные трудоемкие отчеты.
Вот что еще пишет один из участников этого проекта:
My experience (9 years) is with GemStone/S. It is an object repository
*with* behavior. The query interface is the richest I have seen; it is
the full power of Smalltalk. I have also used RDBMS extensively (Oracle
and Sybase). I find them adequate for fairly static knowledge
management, but I would hate to have to try and make them work in an
environment that changes daily, like trading applications, for example.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Sinclair, Вы писали:
R3>>>Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД. S>>Стоит. ООБД оперирует понятиями более высокого порядка, и потому сокращает объем ручной работы.
R3>Ладно, откинем производительность. Выходит так: R3>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля. R3>Я правильно мыслю?
Может я что-то не понимаю, но вроде бы как наследование оно для классов имеет место быть, соответственно я могу класс Кошка унаследовать от класса Животное, но не объект Кошка Мурка от объекта животное в моём подъезде.
По-моему ты что-то путаешь
Здравствуйте, Real 3L0, Вы писали:
R3>Проблема в том, что я сейчас не вижу, какой смысл этих класов в БД (не важно какой — РБД или ООБД). Как понимать их наличие в БД? Мы будем иметь таблицу классов A и таблицу классов B?
Забудь о таблицах. В ООБД не должно быть никаких таблиц. В идеале у объектов нет никаких данных, есть только методы. Поэтому зацикливаться на хранении данных — это значит использовать РБД.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, Real 3L0, Вы писали:
R3>>Проблема в том, что я сейчас не вижу, какой смысл этих класов в БД (не важно какой — РБД или ООБД). Как понимать их наличие в БД? Мы будем иметь таблицу классов A и таблицу классов B? P>Забудь о таблицах. В ООБД не должно быть никаких таблиц. В идеале у объектов нет никаких данных, есть только методы. Поэтому зацикливаться на хранении данных — это значит использовать РБД.
Не а. Не зависимо от того как ты это назовешь, есть оптимальное хранение данных. Смотрим на различные менеджеры памяти и понимаем, что без них система подвергается огромной фрагментации, выборка неэффективна итд.
Просто табличная организация хранения данных одного размера более эффектвна и порвет любой менеджер памяти.
А какой же объект без данных ????? Эдак вообще хранить ничего не надо, одни статические методы
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Считает ли кто-нибудь, что Prevayler и его клоны (Bamboo.Prevalence) являются правильным подходом к OODB? Тем более, что в них появились индексы и даже на XPath?
Здравствуйте, Poudy, Вы писали:
P>Считает ли кто-нибудь, что Prevayler и его клоны (Bamboo.Prevalence) являются правильным подходом к OODB? Тем более, что в них появились индексы и даже на XPath?
И что?
1. Эффективный навигационный доступ возможен только при наличии локальной базы.
2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
Резюме.
Это поделка без каких либо вариантов называться серьезной OODB не может.
Здравствуйте, GlebZ, Вы писали:
GZ>1. Эффективный навигационный доступ возможен только при наличии локальной базы.
Не понимаю довода.
Эффективный — это быстрый или мощный?
навигационный — это просто Select или курсоры?!
локальная база — расположена на моем винчестере?
GZ>2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД.
GZ>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
Насколько я понял, гарантии такие же, как и при использовании РСУБД. Т.е. если РСУБД не упала, всё работает, если упала — ну что тут поделаешь: меняйте провайдера. Транзакций нет.
GZ>Резюме. GZ>Это поделка без каких либо вариантов называться серьезной OODB не может.
Вопрос звучал: правильный ли это подход? Транзакции и изоляцию можно навернуть просто на уровне объектов. Но что насчет подхода?
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, GlebZ, Вы писали:
GZ>>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных.
V>Не проблема. 64-bit Windows на подходе.
Проблема в отношении стоимости оперативной памяти без которой оно не будет шевелиться и дисковой.
Здравствуйте, GlebZ, Вы писали:
P>>Эффективный — это быстрый или мощный? GZ>Да.
Что да Оба что ли?
P>>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД. GZ>Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
Не верю, что известно. Мне непонятно, откуда может взяться разница.
GZ>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных.
Это так, но дело в том, что РСУБД неэффективно использует место и + хранит много дополнительной информации. Возьмем какую-нибудь процессинговую систему: десять миллионов записей о продажах шириной в 200 колонок должна весить около 16 гигабайт, а что получаем на деле?
GZ>Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде.
Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях.
GZ>Что касается prevalyar я в принципе не смотрел, есть ли возможность откатов транзакций. И возможна ли работа в виде Read Commited?
Всё на уровне объектов. Т.е. если белать базу на Prevalayer, кому-то придется повторить все эти фишки с уровнями изоляции в виде некоторой библиотеки.
GZ>Это все и был ответ.
Паааняааатна.
Мы используем Prevayler в реальном проекте для хранения кэша на клиенской стороне. Вещь действительно изящная. Но...
Prevayler фактически это не более чем навороченная сериализация (через "транзакции") сложной структуры данных. Следствие — если начали использовать одну структуру — ее уже нельзя менять. А бывает нужно. Из-за этого приходится извращаться, придумывать спец. форматы объектов, промежуточно сначала сериализовать во что-то простое и т.д.
В общем хотим отказаться.
GZ>Здравствуйте, Poudy, Вы писали:
P>>Здравствуйте, GlebZ, Вы писали: P>>>>Эффективный — это быстрый или мощный? GZ>>>Да. P>>Что да Оба что ли? GZ>Почему бы и нет.
P>>>>Есть еще и виртуальная память. Неизвестно еще, будут ли пассы со свопингом медленнее загрузки страниц в РСУБД. GZ>>>Известно что да. Производители РСУБД убьются за ради одного лишнего обращения к диску. Вся их логика рассчитана на уменьшение стоимости получения объекта или набора объектов. За единицу стоимости обычно берут число обращений и количество прочитанных данных с диска.
P>>Не верю, что известно. Мне непонятно, откуда может взяться разница. GZ>Ой, знаешь сколько механизмов сделано ради этого. Наличие свободного пространства — чтобы можно было быстро впихнуть значение, порядок объектов — которые не обязательно упорядочены по некоторому значению (в пределах страницы всегда) но всегда упорядочены по типам, и соответсвенно загрузка происходит не одной страницы, а сразу по нескольким если высока вероятность что будут прочитаны объекты с других страниц. Экстенты. и т.д. GZ>Раньше было в порядке вещей делать свои драйвера для диска. Чтобы класть данные именно в таком порядке, чтобы не перебегать головкой диска с дорожки на дорожку. Сейчас (IMХО) подразумевается что система хранит файл БД в дефрагментированном состоянии. А свап по определению внутри сильно дефрагментирован.
GZ>>>Второе, 2-3 гига виртуальной памяти на которые может рассчитывать средний комп — не очень много для базы данных. P>>Это так, но дело в том, что РСУБД неэффективно использует место и + хранит много дополнительной информации. Возьмем какую-нибудь процессинговую систему: десять миллионов записей о продажах шириной в 200 колонок должна весить около 16 гигабайт, а что получаем на деле? GZ>Используется оно в том то и дело, очень эффективно. И занимает место для этой цели, действительно больше.
GZ>>>Если РСУБД упала, то все завершенные транзакции остаются завершенными и сохраненными. После завершения транзакции — хоть потоп, все результаты сохранены в постоянном хранилище, и притом в согласованном виде. P>>Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях. GZ>Ну-ну. А если база данных распределенная? И состояние на других хостах уже изменено?
GZ>С уважением, Gleb.
Как человек, самолично реализовавший концепцию Prevayler'a на Питоне отвечу: GZ>1. Эффективный навигационный доступ возможен только при наличии локальной базы.
В целом верно. Prevayler и не должен решать проблему удаленного доступа, он слишком прост для таких задач. Посмотрите, впрочем, поддержку репликации, которую они там пытаются всандалить. GZ>2. Ограничение базы данных по текущей оперативной памяти.(нельзя же память докупать до бесконечности).
Тоже верно. Никаких сомнений/возражений. Однако немало задач есть где это не так уж критично. Зато скорость GZ>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие.
Неверно. Зависит от реализации механизма транзакций. Как это нет гарантии, что была зафиксирована ??? Очень даже есть гарантия....
GZ>Резюме. GZ>Это поделка без каких либо вариантов называться серьезной OODB не может.
В целом верно. "Серьезной" ООБД — не может. Но серьезных ООБД вообще не существует — эта область плохо проработана. Тем не менее для определенного круга задач — гениальное решение.
Здравствуйте, Borisman2, Вы писали:
GZ>>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие. B>Неверно. Зависит от реализации механизма транзакций. Как это нет гарантии, что была зафиксирована ??? Очень даже есть гарантия....
На тот момент, когда я просматривал Prevayler, гарантировалися только моменты сериализации объектов. Что-то изменилось?
GZ>>Резюме. GZ>>Это поделка без каких либо вариантов называться серьезной OODB не может. B>В целом верно. "Серьезной" ООБД — не может. Но серьезных ООБД вообще не существует — эта область плохо проработана. Тем не менее для определенного круга задач — гениальное решение.
Абсолютно согласен. У него есть достаточно большой круг задач где он действительно полезен. Но просто упор делался ООБД. В котором две последние буквы не очень вписываются в концепцию.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Borisman2, Вы писали:
GZ>>>3. Нет никакой гарантии, что важная транзакция была зафиксирована. И в результате она не потеряется при сбое. Скорее это похоже на отсутсвие транзакционного механизма, чем на его присутсвие. B>>Неверно. Зависит от реализации механизма транзакций. Как это нет гарантии, что была зафиксирована ??? Очень даже есть гарантия.... GZ>На тот момент, когда я просматривал Prevayler, гарантировалися только моменты сериализации объектов. Что-то изменилось?
Ничего не изменилось. Сериализация транзакции перед выполнением и есть ее фиксация.
GZ>Абсолютно согласен. У него есть достаточно большой круг задач где он действительно полезен. Но просто упор делался ООБД. В котором две последние буквы не очень вписываются в концепцию.
Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
Здравствуйте, GlebZ, Вы писали:
GZ>Ой, знаешь сколько механизмов сделано ради этого. Наличие свободного пространства — чтобы можно было быстро впихнуть значение, порядок объектов — которые не обязательно упорядочены по некоторому значению (в пределах страницы всегда) но всегда упорядочены по типам, и соответсвенно загрузка происходит не одной страницы, а сразу по нескольким если высока вероятность что будут прочитаны объекты с других страниц. Экстенты. и т.д.
Ну и хорошо, что сделано. IMHO, такие вещи относятся вообще к DB, а не только к RDBMS.
GZ>Раньше было в порядке вещей делать свои драйвера для диска. Чтобы класть данные именно в таком порядке, чтобы не перебегать головкой диска с дорожки на дорожку. Сейчас (IMХО) подразумевается что система хранит файл БД в дефрагментированном состоянии. А свап по определению внутри сильно дефрагментирован.
Ну и хорошо, что подразумевается. Я не вижу никаких причин, препятствующих организовать своп таким же эффективным образом.
P>>Здесь то же самое. Видимо ты недостаточно хорошо изучил вопрос. Все обращения к объектам сохраняются на диск, прежде чем быть выполненными. При восстановлении после сбоя они будут выполнены еще раз. Snap shot кладет всё на диск и забывает об обращениях. GZ>Ну-ну. А если база данных распределенная? И состояние на других хостах уже изменено?
Да нет, всё нормально будет. Ну послушай еще раз: перед собственно выполнением операции на всех хостах, она сериализуется: сама операция сериализуется. Все запросы сначала попадают на диск, а потом уже выполняются. При восстановлении от сбоя все эти запросы прогоняются вновь на сериализованном когда-то в момент снапшота графе объектов.
Здравствуйте, denis_krg, Вы писали:
_>Мы используем Prevayler в реальном проекте для хранения кэша на клиенской стороне. Вещь действительно изящная. Но... _>Prevayler фактически это не более чем навороченная сериализация (через "транзакции") сложной структуры данных. Следствие — если начали использовать одну структуру — ее уже нельзя менять. А бывает нужно. Из-за этого приходится извращаться, придумывать спец. форматы объектов, промежуточно сначала сериализовать во что-то простое и т.д.
Интересно. А разве с таблицами не возкитает такой же подставы? Я вижу проблему в том, что хранилище данных объектов — это просто куча мусора без нормальной структуры, которую можно было бы просматривать и редактировать.
_>В общем хотим отказаться.
По-моему идея Prevalayer никак не нарушится от того, что данные объектов будут храниться в RDB. Ведь идея не в сериализации, ну правда же... Сохраняя объекты в обычную базу вы можете выиграть в обоих направлениях.
Здравствуйте, Borisman2, Вы писали:
B>Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
Полностью согласен. Сколько не читал про эти ООБД и ООСУРБД — никто толком даже не смог объяснить, каким боком они собираются всунуть в эти БД наследование в понятии ООП. По моему, народ услышал термин ООП, разобрался в нем и теперь пытается запихать это ООП куда не поподя. Ну почему движок должен быть обязательно встроен в БД? Разве не достаточно какого-нибудь фреймворка над РБД? Мой ответ — вполне.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Borisman2, Вы писали:
B>>Никто не знает, что такое ООБД ИМХО ОО вообще пока не дотягивает до задач, решаемых БД и возможно ОО+БД вообще никогда не случится.
R3>Полностью согласен. Сколько не читал про эти ООБД и ООСУРБД — никто толком даже не смог объяснить, каким боком они собираются всунуть в эти БД наследование в понятии ООП. По моему, народ услышал термин ООП, разобрался в нем и теперь пытается запихать это ООП куда не
Думаю, что здесь ты не прав. Первые ООСУБД появились в середине восьмидесятых. Когда и ООП не был таким раскрученным брендом, да и SQL еще не стал промышленным стандартом.
R3> поподя. Ну почему движок должен быть обязательно встроен в БД? Разве не достаточно какого-нибудь фреймворка над РБД? Мой ответ — вполне.
Не согласен. Во-первых, на реляционные таблицы тяжело отображать, например, наследование и некоторые типы атрибутов объектов (вектора). Во-вторых, разбиение объекта на ряд реляционных отношений при записи в БД и сборка его из этих отношений при чтении снизят производительность такой настройки. А ООСУБД осуществляют запись/извлечения объекта целиком, что позволяет им получать большую производительность по сравнению с РСУБД (но для объективности нужно сказать, что не для всех задач ООСУБД подходят).
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Во-первых, на реляционные таблицы тяжело отображать, например, наследование и некоторые типы атрибутов объектов (вектора).
Согласен, но после создания некоторой оболочки над БД (фреймворка) всё становится просто. Другой вопрос: объясни мне что такое наследование в понятии ООБД?
E> Во-вторых, разбиение объекта на ряд реляционных отношений при записи в БД и сборка его из этих отношений при чтении снизят производительность такой настройки.
И тут нам поможет оболочка.
E> А ООСУБД осуществляют запись/извлечения объекта целиком, что позволяет им получать большую производительность по сравнению с РСУБД (но для объективности нужно сказать, что не для всех задач ООСУБД подходят).
Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД.
P.S. Замечу, что я не спорю, а пытаюсь разобраться.
Здравствуйте, Sinclair, Вы писали:
R3>>Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД. S>Стоит. ООБД оперирует понятиями более высокого порядка, и потому сокращает объем ручной работы.
Ладно, откинем производительность. Выходит так:
ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля.
Я правильно мыслю?
Здравствуйте, Real 3L0, Вы писали: R3>Ладно, откинем производительность. Выходит так: R3>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля. R3>Я правильно мыслю?
Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы.
Ты описываешь безклассовую схему, где вместо классов используются прототипы. Подобная техника принята в JavaScript. Мне неизвестны ООСУБД, следующие этому подходу. Введение классификации позволяет статически проверить некоторые свойства модели. Для движка это, в свою очередь, означает более богатые перспективы оптимизации — благодаря знаниям об одинаковости поведения групп объектов можно эффективно выполнять массированные операции. Аналогичные ограничения в РСУБД (все записи таблицы имеют одинаковую структуру) позволяют использовать очень эффективные алгоритмы хранения и поиска.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Real 3L0, Вы писали: R3>>Ладно, откинем производительность. Выходит так: R3>>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля. R3>>Я правильно мыслю? S>Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы. S>Ты описываешь безклассовую схему, где вместо классов используются прототипы. Подобная техника принята в JavaScript. Мне неизвестны ООСУБД, следующие этому подходу. Введение классификации позволяет статически проверить некоторые свойства модели.
ИМХО, была такая СУБД -- "Шаман" называлась (Смирнов А., Беляков А., Бронников Г., Филимонов Ю., Чаянов Н. Зачем нужны объектно-ориентированные СУБД // Компьютер Пресс, 1995, 9, сс.46-51.). Там, кажется, тип объекта на лету менять можно было.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>ИМХО, была такая СУБД -- "Шаман" называлась (Смирнов А., Беляков А., Бронников Г., Филимонов Ю., Чаянов Н. Зачем нужны объектно-ориентированные СУБД // Компьютер Пресс, 1995, 9, сс.46-51.).
А электронного варианта нету? E>Там, кажется, тип объекта на лету менять можно было.
Ну, смена типа, строго говоря, не имеет отношения к возможности отнаследоваться от объекта.
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>ИМХО, была такая СУБД -- "Шаман" называлась (Смирнов А., Беляков А., Бронников Г., Филимонов Ю., Чаянов Н. Зачем нужны объектно-ориентированные СУБД // Компьютер Пресс, 1995, 9, сс.46-51.). S>А электронного варианта нету?
Боюсь, что у меня и бумажного варианта уже нет -- этот номер был в библиотеке КБ, в котором я раньше работал. А ссылку я из библиографии своего дисера взял.
E>>Там, кажется, тип объекта на лету менять можно было. S>Ну, смена типа, строго говоря, не имеет отношения к возможности отнаследоваться от объекта.
Строго говоря да. Но Шаман в этом смысле вообще была уникальной. Там понятия типа и наследования были, насколько помню, очень размытыми.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>ИМХО, была такая СУБД -- "Шаман" называлась (Смирнов А., Беляков А., Бронников Г., Филимонов Ю., Чаянов Н. Зачем нужны объектно-ориентированные СУБД // Компьютер Пресс, 1995, 9, сс.46-51.). Там, кажется, тип объекта на лету менять можно было.
IMHO — фрикшоу сплошное.
Здравствуйте, Sinclair, Вы писали:
R3>>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля. R3>>Я правильно мыслю? S>Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы.
Так, что-то я упустил в этой жизни. В чем отличие объектов от классов? Всю жизнь считал что они равны — сначала pascal, потом c++. Почему же тогда название ООБД?
Далее, я другое хотел сказать. Классическая РБД: таблица, в ней строка, строка, строка, ...
Тогда по аналогии, ООБД: объект (пусть класс) с переменными, ещё такой же объект, ещё, ...
Думаю, никому тут не станет проблемой преобразовать РБД -> ООБД -> РБД. Но тут мы вводим наследование в ООБД и создаем новый наследуемый объект. И кто мне теперь скажет, как понять где у нас какие переменные?
Здравствуйте, Real 3L0, Вы писали: R3>Так, что-то я упустил в этой жизни.
Это точно. R3>В чем отличие объектов от классов? Всю жизнь считал что они равны — сначала pascal, потом c++. Почему же тогда название ООБД?
Гм. И где же это они равны? Класс — это тип, объект — это экземпляр. "ОО" означает "объектно-ориентированная", т.е. помимо введения объектов, обладающих состоянием и поведением, есть еще классы и все, что они приносят — наследование, инкапсуляция и полиморфизм.
R3>Далее, я другое хотел сказать. Классическая РБД: таблица, в ней строка, строка, строка, ...
Угу. R3>Тогда по аналогии, ООБД: объект (пусть класс) с переменными, ещё такой же объект, ещё, ...
Ага. R3>Думаю, никому тут не станет проблемой преобразовать РБД -> ООБД -> РБД. Но тут мы вводим наследование в ООБД и создаем новый наследуемый объект.
НЕТ! Объекты ни от кого ничего не наследуют. Наследуют классы. R3>И кто мне теперь скажет, как понять где у нас какие переменные?
Гм. Почему в С++ таких проблем не возникает? Вот есть у нас класс A и класс B:
class A
{
public:
int a;
}
class B: public A
{
public:
int b;
}
Вот есть два экземпляра:
{
A a;
B b;
b.a = 5;
b.b = 10;
}
В чем проблема? А почему теперь в ООБД должна быть какая-то проблема?
... << RSDN@Home 1.1.4 beta 4 rev. 347>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
R3>>В чем отличие объектов от классов? Всю жизнь считал что они равны — сначала pascal, потом c++. Почему же тогда название ООБД? S>Гм. И где же это они равны? Класс — это тип, объект — это экземпляр.
Ааа, вон в каком понятии. Признаю свой мухлёшь в терминологии. Стыдно.
S>Почему в С++ таких проблем не возникает? Вот есть у нас класс A и класс B: S>
S>class A
S>{
S> public:
S> int a;
S>}
S>class B: public A
S>{
S> public:
S> int b;
S>}
S>
S>Вот есть два экземпляра: S>
S>{
S> A a;
S> B b;
S> b.a = 5;
S> b.b = 10;
S>}
S>
S>В чем проблема? А почему теперь в ООБД должна быть какая-то проблема?
Проблема в том, что я сейчас не вижу, какой смысл этих класов в БД (не важно какой — РБД или ООБД). Как понимать их наличие в БД? Мы будем иметь таблицу классов A и таблицу классов B?
Здравствуйте, Sinclair, Вы писали:
S>Вообще, программирование, как и любая инженерная область, довольно-таки точная дисциплина. Мелкие и несущественные детали формулировок очень сильно меняют смысл. В термины стоит тщательно вдумываться.
+1. Различать понятия, пользоваться именно тем понятием, которые нужно и конкретно оговаривать ответы, не оставляя повода для их разных истолкований, меня научили ещё в вузе, когда я прилично на этом погорел. Просто на меня снизошла очередная временная деградация.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, Sinclair, Вы писали:
R3>>>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля. R3>>>Я правильно мыслю? S>>Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы.
R3>Так, что-то я упустил в этой жизни. В чем отличие объектов от классов? Всю жизнь считал что они равны — сначала pascal, потом c++. Почему же тогда название ООБД?
Значит не работал с Delphi. Там есть еще и метаклассы, которые являются сущностью класса. Плюс статические переменные.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
Сорри, что подзабросил ветку.
P>>Забудь о таблицах. В ООБД не должно быть никаких таблиц. В идеале у объектов нет никаких данных, есть только методы. Поэтому зацикливаться на хранении данных — это значит использовать РБД. S> Не а. Не зависимо от того как ты это назовешь, есть оптимальное хранение данных. Смотрим на различные менеджеры памяти и понимаем, что без них система подвергается огромной фрагментации, выборка неэффективна итд.
Ну.. Оптимально в существующих RAM. Это раз. Потом там нет таблиц, там деревья и массивы. Таблицы — это ж абстракция, как я понимаю. Если говорят о таблицах применительно к DB, я сразу вижу tuples. Так что, в ООБД не должно быть никаких таблиц .
S> Просто табличная организация хранения данных одного размера более эффектвна и порвет любой менеджер памяти.
Только для существующих RAM. Но даже если не умничать, организация в массивах не имеет отношения к таблицам всетки. RDB — это же ralational, а не tabled... ну правда же.
S> А какой же объект без данных ????? Эдак вообще хранить ничего не надо, одни статические методы
Пусть будут данные. Я свято верю, что смысл объектов — в посылке сообщения. Ну на крайнк в реализации интерфейсов. Значит нет никаких явных данных.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, Serginio1, Вы писали:
P>Сорри, что подзабросил ветку.
P>>>Забудь о таблицах. В ООБД не должно быть никаких таблиц. В идеале у объектов нет никаких данных, есть только методы. Поэтому зацикливаться на хранении данных — это значит использовать РБД. S>> Не а. Не зависимо от того как ты это назовешь, есть оптимальное хранение данных. Смотрим на различные менеджеры памяти и понимаем, что без них система подвергается огромной фрагментации, выборка неэффективна итд.
P>Ну.. Оптимально в существующих RAM. Это раз. Потом там нет таблиц, там деревья и массивы. Таблицы — это ж абстракция, как я понимаю. Если говорят о таблицах применительно к DB, я сразу вижу tuples. Так что, в ООБД не должно быть никаких таблиц .
. Это и есть табличная органицация данных.
Все таки я рассматриваю разницу между ними только в работе с данными. Так создание объектной надстройки на локальной РБД не составляет труда. Создается объект над записью (ми) в который эти записи считываются. Самый простой аналог это 1С. Это надстройка над РБД, но в которой нет понятий таблиц итд. S>> Просто табличная организация хранения данных одного размера более эффектвна и порвет любой менеджер памяти.
P>Только для существующих RAM. Но даже если не умничать, организация в массивах не имеет отношения к таблицам всетки. RDB — это же ralational, а не tabled... ну правда же.
S>> А какой же объект без данных ????? Эдак вообще хранить ничего не надо, одни статические методы P>Пусть будут данные. Я свято верю, что смысл объектов — в посылке сообщения. Ну на крайнк в реализации интерфейсов. Значит нет никаких явных данных.
Мне ближе не абстрактные понятия, а конкретная реализация, коих может быть множество, но объектов без данных не бывает по определению.
Хотя и не буду особо настаивать.
... << RSDN@Home 1.1.4 beta 4 rev. 303>>
и солнце б утром не вставало, когда бы не было меня
А где в выделенном слово "таблица"? 
.
