БредятинаOLEG_2005пропущено...


Как без EAV вы представляете себе хранение произвольного набора атрибутов?
Понадобилась еще одна характеритика объекта - добавили. Что здесь нужно представлять?:)

Решение с изменением структуры таблицы является нежизнеспособным.

БредятинаOLEG_2005Классический подход - это использование таблиц с фиксированным числом столбцов, в которых хранятся значения?

Такой подход не предписывает и реляционная технология. Его вели в практику (и, тем самым, - Вас в заблуждение) разработчики "реляционных" СУБД.
OLEG_2005А как быть, когда набор атрибутов заранее неизвестен?
Добавить, когда станет известным - это же очевидно.

Могли бы вы объяснить вашу идею, она непонятна.
Когда вы говорить добавить атрибут, в имеете в виду добавить столбец в таблицу?

БредятинаOLEG_2005Вы имеете в виду, каждый раз изменять структуру таблицы?
Я имею в виду, что пользователь, конечно, может, добавлять характеристики объектов (даже в реляционной технологии нет понятия "таблица"), точнее ему просто должна быть предоставлена такая возможность. Иначе - это вообще не СУБД.

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

БредятинаOLEG_2005Решение с изменением структуры таблицы является нежизнеспособным.
Так точно, но Вы опять забыли добавить ключевые слова - в СУБД, которую мне навязали "жизненные обстоятельства":)

Да, я говорю об РСУБД, так как большая часть данных отлична опивывается в терминах РСУБД, но я также не вижу решения данной задачи в нереляционных СУБД.

БредятинаOLEG_2005Могли бы вы объяснить вашу идею, она непонятна.
Когда вы говорить добавить атрибут, в имеете в виду добавить столбец в таблицу?
Это не моя идея. В классической объектной модели, как и в реляционной, нет понятий "столбец" и "таблица". Добавить характеристику в объект. Только и всего. Конечно, Вы можете использовать такую аналогию - "столбец" в "таблицу", но, учитывая отсутсвие у Вас знаний даже о таких фундаментальных продуктах технологии баз данных, как GT.M, эта аналогия может Вас привести к заблуждению:)

В объектной СУБД есть, наверное, понятие объект и атрибут. Мне непонятно, как происходит поиск в таких системах по вновь добавленному атрибуту.
В РСУБД для эффективного использования запросов, мы создаем схему БД и соответствующие индексы. А как происходит поиск по атрибуту, например, в GT.M?

БредятинаOLEG_2005Вариант с постоянным изменением структуры таблицы неприменим.
Во-первых, в многопользовательской системе это небезопасно, во-вторых, в одной таблице хранятся данные многих пользователей и соответственно независимо изменить структуру для каждого из тысяч пользователей не представляется возможным.
Вы опять забыли про ключевую фразу:)
Мне остается только принести соболезнования... Надеюсь, что товарищи по несчастью, которые тоже используют "Вашу" СУБД, в которой практически ничего не представляется возможным, Вам, все-таки, помогут найти единственно верное решение:)

Походе в наших рассуждениях мы сильно ушли от темы.

БредятинаOLEG_2005Да, я говорю об РСУБД, так как большая часть данных отлична опивывается в терминах РСУБД, но я также не вижу решения данной задачи в нереляционных СУБД.
Да, конечно, отлично описывается. Это видно по форуму:)

Это только часть задачи, остальная часть довольно хорошо описывается в РСУБД.

БредятинаOLEG_2005В объектной СУБД есть, наверное, понятие объект и атрибут. Мне непонятно, как происходит поиск в таких системах по вновь добавленному атрибуту.

Атрибут - это другое. Объект и характеристика - так правильно (у характеристики может быть много артибутов: тип, наименование и т.д.). Поиск происходит точно так же, как и по ранее добавленным. Я даже не могу представить какая тут может быть проблема. А что в "реляционной системе" есть какая-то проблема с поиском, когда, как Вы говорите, добавляется "столбец" в "таблицу"???
OLEG_2005В РСУБД для эффективного использования запросов, мы создаем схему БД и соответствующие индексы. А как происходит поиск по атрибуту, например, в GT.M?
GT.M - это среда для создания СУБД:)
В СУБД, основанных на классической объектной модели, запросы используются намного эффективнее, чем в "Р"СУБД.

А имел в виду, что изменяться структуру таблицы, когда система в работе недопустимо.
Для эффективного запроса по столбцу нужно добавлять индексы в РСУБД, видимо нечто подобное и в объектных СУБД?

БредятинаOLEG_2005А имел в виду, что изменяться структуру таблицы, когда система в работе недопустимо.
Для эффективного запроса по столбцу нужно добавлять индексы в РСУБД, видимо нечто подобное и в объектных СУБД?
Ничего подобного даже близко нет. Налитие и тип индекса - это просто атрибуты характеристики объекта. Добавляете характеристику, и все. При чем здесь в работе система или не в работе???

Я имею в виду, что решение с изменением структуры таблицы для добавления атрибутов в РСУБД, каждый раз когда пользователь добавляет новый атрибут, нереализуемо на практике.

БредятинаOLEG_2005Я имею в виду, что решение с изменением структуры таблицы для добавления атрибутов в РСУБД, каждый раз когда пользователь добавляет новый атрибут, нереализуемо на практике.
Это изначально понятно былою Это одна из тех "частей", а в целом "довольно хорошо":)

Поэтому тема поста связана с EAV.

БредятинаOLEG_2005Я имею в виду, что решение с изменением структуры таблицы для добавления атрибутов в РСУБД, каждый раз когда пользователь добавляет новый атрибут, нереализуемо на практике.
Это изначально понятно былою Это одна из тех "частей", а в целом "довольно хорошо":)

Но если будут высказаны идеи реализации в не РСУБД, это тоже может быть интересно.