guest_20040621> Что касается схемы,то я опять не понял о чем речь. Если о таблицах в БД и
> связях между ними, то здесь жесткая и постоянная схема,она не меняется
> никогда.

Хм... никто ничего менять не предлагает. Помните про два уровня представления - объектный и SQL? - это все о том же. Есть у Вас какая-то структура данных, - очень хорошо, не надо ее менять. Надо ее просто описать. И строить классификатор(ы) на основании этого описания. Вы же говорили про объектный подход? - ничего более объектного и придумать нельзя. ;)

> Я связываю вопрос классификации именно с вопросом наполнения хранилища.

Количественного? Напрасно. _Правильно_ построенная классификация не зависит/слабо зависит от количества классифицируемых сущностей. От времени она зависит гораздо больше.

1. Сам факт, что структура работает,говорить о том,что она описана. И она писана,на уровне sql-деклараций,с ограничениями ссылочной целостности и т.д. Сами же приложения, написанные на скрипте могут следовать какой угодно идеологии, в любом случае этим скриптам доступен как локальный,так и глобальный контекст,т.е. значения свойств,их идентификация,так же,как и самих объектов.
2.Наполненное и первоначально классифицированное хранилище можно реорганизовывать со временем,даже простым перетаскиванием веток дерева,без какого либа ущерба для идентификации.Это работает уже.

guest_20040621> Сам факт, что структура работает,говорить о том,что она описана.

По-моему, я выражаюсь предельно недвусмысленно. :( У Вас есть некоторое количество таблиц. Это _физический уровень_ (или SQL, или реляционный, - как угодно). Метаописание этих таблиц у Вас есть? Какие сущности они содержат? Из чего состоят? Вы понимаете, что здесь объектами даже и не пахнет? Вы говорите про набор таблиц, - а они ничем более набора таблиц _не являются_.

> Наполненное и первоначально классифицированное хранилище можно
> реорганизовывать со временем,даже простым перетаскиванием веток дерева

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

Вот такого типа метаданные,если выражаться на языке sql
CREATE TABLE NODE(
nID IDENT64 DEFAULT 0 NOT NULL,
nParent IDENT64 DEFAULT 0 NOT NULL,
nName dName NOT NULL,
....
PRIMARY KEY(nID),
CONSTRAINT PAR_NODE FOREIGN KEY(nParent) REFERENCES NODE(nID)
);
.....
CREATE GENERATOR nID_NODE_GEN;

Programmer_Ortodox guest_20040621> Сам факт, что структура работает,говорить о том,что она описана.

По-моему, я выражаюсь предельно недвусмысленно. :( У Вас есть некоторое количество таблиц. Это _физический уровень_ (или SQL, или реляционный, - как угодно). Метаописание этих таблиц у Вас есть? Какие сущности они содержат? Из чего состоят? Вы понимаете, что здесь объектами даже и не пахнет? Вы говорите про набор таблиц, - а они ничем более набора таблиц _не являются_.

> Наполненное и первоначально классифицированное хранилище можно
> реорганизовывать со временем,даже простым перетаскиванием веток дерева

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

Вот такого типа метаданные,если выражаться на языке sql
CREATE TABLE NODE(
nID IDENT64 DEFAULT 0 NOT NULL,
nParent IDENT64 DEFAULT 0 NOT NULL,
nName dName NOT NULL,
....
PRIMARY KEY(nID),
CONSTRAINT PAR_NODE FOREIGN KEY(nParent) REFERENCES NODE(nID)
);
.....
CREATE GENERATOR nID_NODE_GEN;

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

Увы, у меня в базе не декларируются какие-либо описания, связанные с предметной областью, только древесные структуры в самом общем виде. И ничего больше.

И все таки мне бы очень хотелось услышать мнения людей, набивших руку в использовании CASE-средств, можно ли проектировать рекурсивные (самоописывающиеся) структуры данных или нет!?

ASU guest_20040621 ASUЕсть хорошая реляционная модель, есть хорошая объектная модель, включающая в себя понятие "объектной фабрики" (object factory). OF инкапсулирует в себе работу с любым хранилищем данных, в том числе, и с RDB. Все разговоры об объектных СУБД, "надстройках" над RDBMS и т.п. - это профанация либо объектной парадигмы, либо реляционной модели (это в полной мере относится и к IBM, и к Oracle и другим грандам программной индустрии)Не могу похвастать, что знаком с концепцией Oracle или IBM. Что хотелось отметить (к воспросу о том, почему imho неоправданна строгая реализация объектной модели в реляционной dbms): структура данных для объектной модели в реляционной dbms в общем случае не оптимальна. Если есть необходимость хранить объекты, - нужны другие инструменты, не реляционныеРеляционные модели (расширенная, в том числе), описанные Коддом, довольно богаты по своим возможностям. Реляционные СУБД - частные взгляды на модели Кодда, взгляды более узкие, накладывающие ограничения, отсутствующие в исходных моделях. Поэтому Вы правильно говорите о неоптимальности хранения в RDBMS, но напрасно, IMHO, распространяете это утверждение на все "реляционные инструменты".
Есть и другие проблемы при хранении объектов в любом хранилище. Например, должна поддерживаться инкапсуляция, а значит атрибуты объектов не должны быть видимы. Как в таком случае найти объекты, обладающие нужными свойствами (в данном случае, соответствующими значениями атрибутов)? Загружать в память каждый объект и инициализировать его, только для того, чтобы узнать значение атрибута? Накладно, но как иначе обеспечить инкапсуляцию? И подобных вопросов достаточно много...

>Например, должна поддерживаться инкапсуляция, а значит атрибуты >объектов не должны быть видимы. Как в таком случае найти объекты, >обладающие нужными свойствами (в данном случае, соответствующими >значениями атрибутов)? Загружать в память каждый объект и >инициализировать его, только для того, чтобы узнать значение атрибута? >Накладно, но как иначе обеспечить инкапсуляцию?

В предложенной реализации эти вопросы решены,причем радикально.
Атрибуты всегда хранятся отдельно от объектов. Можно бросить взгляд(т.е.создать ракурс) на все хранилище, с точки зрения наименования конкретного свойства,и увидеть,у какаих объектов такое свойство есть; можно "бросить взгляд" на хранилище,с точки зрения конкретного значения(значений) и увидеть у каких свойств эти значения и,каким объектам эти значения и св-ва принадлежат.
-----------------------------
При работе,лично я исхожу из реальных объектов,существующих в реальной жизни,а формализм наверное приложится.

В ближайшие дни я приведу здесь наглядные и работающие иллюстрации к сказанному.

ASU guest_20040621 ASUЕсть хорошая реляционная модель, есть хорошая объектная модель, включающая в себя понятие "объектной фабрики" (object factory). OF инкапсулирует в себе работу с любым хранилищем данных, в том числе, и с RDB. Все разговоры об объектных СУБД, "надстройках" над RDBMS и т.п. - это профанация либо объектной парадигмы, либо реляционной модели (это в полной мере относится и к IBM, и к Oracle и другим грандам программной индустрии)Не могу похвастать, что знаком с концепцией Oracle или IBM. Что хотелось отметить (к воспросу о том, почему imho неоправданна строгая реализация объектной модели в реляционной dbms): структура данных для объектной модели в реляционной dbms в общем случае не оптимальна. Если есть необходимость хранить объекты, - нужны другие инструменты, не реляционныеРеляционные модели (расширенная, в том числе), описанные Коддом, довольно богаты по своим возможностям. Реляционные СУБД - частные взгляды на модели Кодда, взгляды более узкие, накладывающие ограничения, отсутствующие в исходных моделях. Поэтому Вы правильно говорите о неоптимальности хранения в RDBMS, но напрасно, IMHO, распространяете это утверждение на все "реляционные инструменты".
Есть и другие проблемы при хранении объектов в любом хранилище. Например, должна поддерживаться инкапсуляция, а значит атрибуты объектов не должны быть видимы. Как в таком случае найти объекты, обладающие нужными свойствами (в данном случае, соответствующими значениями атрибутов)? Загружать в память каждый объект и инициализировать его, только для того, чтобы узнать значение атрибута? Накладно, но как иначе обеспечить инкапсуляцию? И подобных вопросов достаточно много...

Интересно узнать какие лично Вы можете сформулировать требования к универсальному ХРАНИЛИЩУ информации(любой!)?