Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, Sinclair, Вы писали:

R3>>>Это конечно хорошо, но стоит ли овчинка выделки, если я тоже самое могу реализовать и в РБД.
S>>Стоит. ООБД оперирует понятиями более высокого порядка, и потому сокращает объем ручной работы.

R3>Ладно, откинем производительность. Выходит так:
R3>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля.
R3>Я правильно мыслю?

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

Здравствуйте, Real 3L0, Вы писали:
R3>Ладно, откинем производительность. Выходит так:
R3>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля.
R3>Я правильно мыслю?
Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы.
Ты описываешь безклассовую схему, где вместо классов используются прототипы. Подобная техника принята в JavaScript. Мне неизвестны ООСУБД, следующие этому подходу. Введение классификации позволяет статически проверить некоторые свойства модели. Для движка это, в свою очередь, означает более богатые перспективы оптимизации — благодаря знаниям об одинаковости поведения групп объектов можно эффективно выполнять массированные операции. Аналогичные ограничения в РСУБД (все записи таблицы имеют одинаковую структуру) позволяют использовать очень эффективные алгоритмы хранения и поиска.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Real 3L0, Вы писали:
R3>>Ладно, откинем производительность. Выходит так:
R3>>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля.
R3>>Я правильно мыслю?
S>Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы.
S>Ты описываешь безклассовую схему, где вместо классов используются прототипы. Подобная техника принята в JavaScript. Мне неизвестны ООСУБД, следующие этому подходу. Введение классификации позволяет статически проверить некоторые свойства модели.

ИМХО, была такая СУБД -- "Шаман" называлась (Смирнов А., Беляков А., Бронников Г., Филимонов Ю., Чаянов Н. Зачем нужны объектно-ориентированные СУБД // Компьютер Пресс, 1995, 9, сс.46-51.). Там, кажется, тип объекта на лету менять можно было.

Здравствуйте, eao197, Вы писали:

E>ИМХО, была такая СУБД -- "Шаман" называлась (Смирнов А., Беляков А., Бронников Г., Филимонов Ю., Чаянов Н. Зачем нужны объектно-ориентированные СУБД // Компьютер Пресс, 1995, 9, сс.46-51.).
А электронного варианта нету?
E>Там, кажется, тип объекта на лету менять можно было.
Ну, смена типа, строго говоря, не имеет отношения к возможности отнаследоваться от объекта.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, eao197, Вы писали:

E>>ИМХО, была такая СУБД -- "Шаман" называлась (Смирнов А., Беляков А., Бронников Г., Филимонов Ю., Чаянов Н. Зачем нужны объектно-ориентированные СУБД // Компьютер Пресс, 1995, 9, сс.46-51.).
S>А электронного варианта нету?

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

E>>Там, кажется, тип объекта на лету менять можно было.
S>Ну, смена типа, строго говоря, не имеет отношения к возможности отнаследоваться от объекта.

Строго говоря да. Но Шаман в этом смысле вообще была уникальной. Там понятия типа и наследования были, насколько помню, очень размытыми.

Здравствуйте, 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;
}

В чем проблема? А почему теперь в ООБД должна быть какая-то проблема?

Здравствуйте, 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. А как это произойдет -- это уже забота ООБД.

Здравствуйте, 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?

Здравствуйте, Real 3L0, Вы писали:

R3>Проблема в том, что я сейчас не вижу, какой смысл этих класов в БД (не важно какой — РБД или ООБД). Как понимать их наличие в БД? Мы будем иметь таблицу классов A и таблицу классов B?
Забудь о таблицах. В ООБД не должно быть никаких таблиц. В идеале у объектов нет никаких данных, есть только методы. Поэтому зацикливаться на хранении данных — это значит использовать РБД.

Здравствуйте, Poudy, Вы писали:

P>Забудь о таблицах. В ООБД не должно быть никаких таблиц.

В чем тогда выражается выделенное?

Здравствуйте, Real 3L0, Вы писали:

R3>В чем тогда выражается выделенное?
А где в выделенном слово "таблица"?
Оффтоп
Вообще, программирование, как и любая инженерная область, довольно-таки точная дисциплина. Мелкие и несущественные детали формулировок очень сильно меняют смысл. В термины стоит тщательно вдумываться. Пример: объект и класс — совершенно разные вещи. Ламеры могут произвольно менять их местами, настоящие программисты — нет. Второй пример: таблица и база данных. В соответствующий форум еженедельно постятся десятки людей, которые используют эти термины взаимозаменяемо. Настоящие программисты так не делают. Более того, они даже отличают термин "база данных" от термина "система управления базами данных". Освоение правильной терминологии весьма ощутимо помогает улучшить эффективность коммуникации с коллегами.
/Оффтоп

Здравствуйте, Sinclair, Вы писали:

R3>>В чем тогда выражается выделенное?
S> А где в выделенном слово "таблица"?


Нет, забудем про таблицы. Я имел ввиду, в чем же тогда выражается, что это база данных?

Здравствуйте, Sinclair, Вы писали:

S>Вообще, программирование, как и любая инженерная область, довольно-таки точная дисциплина. Мелкие и несущественные детали формулировок очень сильно меняют смысл. В термины стоит тщательно вдумываться.

+1. Различать понятия, пользоваться именно тем понятием, которые нужно и конкретно оговаривать ответы, не оставляя повода для их разных истолкований, меня научили ещё в вузе, когда я прилично на этом погорел. Просто на меня снизошла очередная временная деградация.

Здравствуйте, Real 3L0, Вы писали:

R3>
R3>Нет, забудем про таблицы. Я имел ввиду, в чем же тогда выражается, что это база данных?
В поддержке определенных свойств. В основном, это:
— устойчивость к сбоям
— многопользовательская работа
— ассоциативный поиск/поддержка декларативного языка запросов

Здравствуйте, Sinclair, Вы писали:

S>- ассоциативный поиск/поддержка декларативного языка запросов

Хорошо. Остановимся на этом. В общих чертах представил, но надо пощупать.

Здравствуйте, Real 3L0, Вы писали:

R3>Здравствуйте, Sinclair, Вы писали:

R3>>>ООБД. Объект. Объект в БД. У объекта поля. Поменяли значение поля. Записали состояние объекта. От объекта наследовался другой объект. Прочитали значение поля.
R3>>>Я правильно мыслю?
S>>Нет. То, что ты описываешь, это не ООП в его привычном смысле. В "мэйнстримовом" ООП наследуются не объекты, а классы.

R3>Так, что-то я упустил в этой жизни. В чем отличие объектов от классов? Всю жизнь считал что они равны — сначала pascal, потом c++. Почему же тогда название ООБД?

Значит не работал с Delphi. Там есть еще и метаклассы, которые являются сущностью класса. Плюс статические переменные.

Здравствуйте, Poudy, Вы писали:

P>Здравствуйте, Real 3L0, Вы писали:

R3>>Проблема в том, что я сейчас не вижу, какой смысл этих класов в БД (не важно какой — РБД или ООБД). Как понимать их наличие в БД? Мы будем иметь таблицу классов A и таблицу классов B?
P>Забудь о таблицах. В ООБД не должно быть никаких таблиц. В идеале у объектов нет никаких данных, есть только методы. Поэтому зацикливаться на хранении данных — это значит использовать РБД.
Не а. Не зависимо от того как ты это назовешь, есть оптимальное хранение данных. Смотрим на различные менеджеры памяти и понимаем, что без них система подвергается огромной фрагментации, выборка неэффективна итд.
Просто табличная организация хранения данных одного размера более эффектвна и порвет любой менеджер памяти.
А какой же объект без данных ????? Эдак вообще хранить ничего не надо, одни статические методы

Здравствуйте, Serginio1, Вы писали:

Сорри, что подзабросил ветку.

P>>Забудь о таблицах. В ООБД не должно быть никаких таблиц. В идеале у объектов нет никаких данных, есть только методы. Поэтому зацикливаться на хранении данных — это значит использовать РБД.
S> Не а. Не зависимо от того как ты это назовешь, есть оптимальное хранение данных. Смотрим на различные менеджеры памяти и понимаем, что без них система подвергается огромной фрагментации, выборка неэффективна итд.

Ну.. Оптимально в существующих RAM. Это раз. Потом там нет таблиц, там деревья и массивы. Таблицы — это ж абстракция, как я понимаю. Если говорят о таблицах применительно к DB, я сразу вижу tuples. Так что, в ООБД не должно быть никаких таблиц .

S> Просто табличная организация хранения данных одного размера более эффектвна и порвет любой менеджер памяти.

Только для существующих RAM. Но даже если не умничать, организация в массивах не имеет отношения к таблицам всетки. RDB — это же ralational, а не tabled... ну правда же.

S> А какой же объект без данных ????? Эдак вообще хранить ничего не надо, одни статические методы
Пусть будут данные. Я свято верю, что смысл объектов — в посылке сообщения. Ну на крайнк в реализации интерфейсов. Значит нет никаких явных данных.