ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обектную СУБД
18 сообщений из 68, страница 3 из 3
  3  все
Обектную СУБД
    #33282425
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
vadiminfo shuklin
Ващето это как раз та цель, к которой стремятся ООСУБД. Стереть грань между дисковой памятью и RAM.

А раньше ООСУБД претендовала на большее, чем на физические какие-то проблемы. Или это тока Ваша стремится? Остальные как и раньше более амбициозные цели преследуют?

Это одна из целей. Одно другому не мешает. "Xopoшo быть здoрoвым и бoгaтым"
...
Рейтинг: 0 / 0
21.09.2005, 20:04
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33282874
mod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mod
Участник
ModelR Об том и речь, что EAV уже фактически получилось... Хочется другого.
Внесение данных можно и блокировать если идут изменения....
shuklin Одной таблицей не обойтись точно. Надо 3-4 таблицы однозначно.
И ещё проблема в том что хочется хранить методы. С РСУБД я её решил используя Perl как интерпритатор для хранимых функций.... Но опять некрасиво... Всё-таки "толстый" клиент мастрю....
Alexey Rovdo свет на .NET не сошёлся, однако тады придётся ещё и язык учить и как в нём всё делается. Оно конечно Java выучить не лишне...
...
Рейтинг: 0 / 0
22.09.2005, 09:51
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33283137
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ModelR
Участник
shuklin it depends
Зачем нужны воопче нафик субд (неважно какие "О", "Р", "ОО", "XML") - периодицкий дамп всей памяти на диск и рестор с нее - и фсё.

Ващето это как раз та цель, к которой стремятся ООСУБД. Стереть грань между дисковой памятью и RAM. Есть просто классы и объекты, методы у объектов просто выполняются. Независимо от рестартов оборудования и приложений. Никаких файлов с документами, электронными таблицами - все всегда запущено и всегда в памяти. Все приложения всегда в памяти. Все документы всегда загружены. Все многопользовательские конфликты разруливаются аффтоматом ... лепота.
Не... Разница не между дисковой памятью и RAM. Разница между синхронным полностью контролируемым процессом и сервером, обслуживающим асинхронные процессы. Процесс не может надеется, что сервер хранит данные по тому же адресу, где он их оставил в прошлый раз.
Дамп не помогает.
И просто класс не заработает - нужно его модифицировать чтобы он стал способным к хранению. И обработку для удаления надо в нем прописать, сборкой мусора не обойдешся. И каким именно аффтоматом разруливать многопользовательские конфликты нужно прописать и т.д.
В общем придется решать все те же проблемы, но другими методами - изнутри классов что означает с учетом языковых ньюансов.
Потенциально оно мощнее, но насчет проще ...:(.
...
Рейтинг: 0 / 0
22.09.2005, 11:32
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33283321
mod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mod
Участник
К слову:
http://ycmi.med.yale.edu/nadkarni/eav_CR_contents.htm
Приходится пока вот так...
...
Рейтинг: 0 / 0
22.09.2005, 12:29
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33283428
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
modshuklin Одной таблицей не обойтись точно. Надо 3-4 таблицы однозначно.
Не знаю, какую проблему ты решаешь, но одной для частного случая хранения аттрибутов объектов хватает с головой. а 4-х ватает ваще для всего чего угодно http://www.microsoft.ru/offext/details.aspx?id=620

Например таблица из 3х колонок.
GUID объекта,
GUID аттрибута,
SQL_VARIANT значение аттрибута.

если заметить, что GUID объектов могут описывать аттрибуты (тоесть первая и вторая колонки могут содержать одинаковые значения GUID), то объект может быть описателем собственного аттрибута. Одной такой таблицы хватает чтоб описать орграф с раскрашенными ребрами.

Все остальное просто хардкодится в приложении в виде констант с GUIDs.


modИ ещё проблема в том что хочется хранить методы.

Похоже на то что надо тебе на Cerebrum внимательнее взглянуть. Хотябы просто для ознакомления. Одни задачи всеже решаем.
...
Рейтинг: 0 / 0
22.09.2005, 12:56
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33283436
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
ModelR shuklin it depends
Зачем нужны воопче нафик субд (неважно какие "О", "Р", "ОО", "XML") - периодицкий дамп всей памяти на диск и рестор с нее - и фсё.

Ващето это как раз та цель, к которой стремятся ООСУБД. Стереть грань между дисковой памятью и RAM. Есть просто классы и объекты, методы у объектов просто выполняются. Независимо от рестартов оборудования и приложений. Никаких файлов с документами, электронными таблицами - все всегда запущено и всегда в памяти. Все приложения всегда в памяти. Все документы всегда загружены. Все многопользовательские конфликты разруливаются аффтоматом ... лепота.
Не... Разница не между дисковой памятью и RAM. Разница между синхронным полностью контролируемым процессом и сервером, обслуживающим асинхронные процессы. Процесс не может надеется, что сервер хранит данные по тому же адресу, где он их оставил в прошлый раз.
Дамп не помогает.
И просто класс не заработает - нужно его модифицировать чтобы он стал способным к хранению. И обработку для удаления надо в нем прописать, сборкой мусора не обойдешся. И каким именно аффтоматом разруливать многопользовательские конфликты нужно прописать и т.д.
В общем придется решать все те же проблемы, но другими методами - изнутри классов что означает с учетом языковых ньюансов.
Потенциально оно мощнее, но насчет проще ...:(.

Вот этим всем ООСУБД и занимается, снимая эти заботы с рядовых разработчиков. Разработчик же просто считает, что он программит классы, экземпляры которых всегда находятся в RAM а не на HD. И использует обычные указатели память-память (а что там закулисами - дело системных программистов, всякие индексы мягких ссылок это не забота прикладников)
...
Рейтинг: 0 / 0
22.09.2005, 12:59
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33283525
mod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mod
Участник
shuklin

Например таблица из 3х колонок.
GUID объекта,
GUID аттрибута,
SQL_VARIANT значение аттрибута.

Дык я так и делал через SQL_VARIANT. А таблиц 4:
1. классы\подклассы\наследование(id_class, class_name, id_superclass) с рекурсивной ссылкой
2. объекты(id, имя)
3. аттрибуты(id, наименование, тип)
4. значения аттрибутов для объекта(id_object,id_attribute, attr_value SQL_VARIANT)
Вот и четыре таблицы уже... Гнусь...
Плюс:
5. связи -(id связи, id1,id2,класс/объект,класс/объект,связь)
Вот тут вот в таблице связей приходится формулу хранить....
...
Рейтинг: 0 / 0
22.09.2005, 13:24
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33283732
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
mod shuklin

Например таблица из 3х колонок.
GUID объекта,
GUID аттрибута,
SQL_VARIANT значение аттрибута.

Дык я так и делал через SQL_VARIANT. А таблиц 4:
1. классы\подклассы\наследование(id_class, class_name, id_superclass) с рекурсивной ссылкой
В первую колонку моего варианта суем id_class, во вторую
id_superclass в третью class_name. То что эта строка относится к классу понимаем на основе уникального GUID в первой колонке - это ведь id класса
Запутано, но работает.
mod2. объекты(id, имя)
В первую - id. во вторую - хардкодед GUID_Name_Attribute, в третью - имя. Как раз аттрибут объекта - имя, со значением. Эту таблицу экономим ваще без сожалений.
mod
3. аттрибуты(id, наименование, тип)
Ид аттрибута - в первую колонку. Чтоб узнать имя аттрибута - в той же таблице объект с ID аттрибута и значением в аттрибуте GUID_Name_Attribute равным его имени. Тип в другой строке с тем же ID в первой колонке, GUID_Type_Attribute во второй и собственно дескриптором типа в варианте.

mod
4. значения аттрибутов для объекта(id_object,id_attribute, attr_value SQL_VARIANT)
Опять же 1 к 1 - та же таблица.

mod
Вот и четыре таблицы уже... Гнусь...
Пока хватило одной...
mod
Плюс:
5. связи -(id связи, id1,id2,класс/объект,класс/объект,связь)
связь между объектами опять же тривиальна в той же таблице. Аттрибут объекта=связи. первая колонка ID объекта, вторая ID аттрибута. третья в варианте - GUID объекта на который указывает связь.

Итого получили орграф с раскрашенными ребрами в одной таблице.
Эта таблица - очень близкая аналогия модели данных Cerebrum.

mod
Вот тут вот в таблице связей приходится формулу хранить....

Да. с формулами головная боль отдельная ...
...
Рейтинг: 0 / 0
22.09.2005, 14:17
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33284392
mod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mod
Участник
shuklin mod shuklin

Например таблица из 3х колонок.
GUID объекта,
GUID аттрибута,
SQL_VARIANT значение аттрибута.

Дык я так и делал через SQL_VARIANT. А таблиц 4:
1. классы\подклассы\наследование(id_class, class_name, id_superclass) с рекурсивной ссылкой
В первую колонку моего варианта суем id_class, во вторую
id_superclass в третью class_name. То что эта строка относится к классу понимаем на основе уникального GUID в первой колонке - это ведь id класса
Запутано, но работает.
mod2. объекты(id, имя)
В первую - id. во вторую - хардкодед GUID_Name_Attribute, в третью - имя. Как раз аттрибут объекта - имя, со значением. Эту таблицу экономим ваще без сожалений.
mod
3. аттрибуты(id, наименование, тип)
Ид аттрибута - в первую колонку. Чтоб узнать имя аттрибута - в той же таблице объект с ID аттрибута и значением в аттрибуте GUID_Name_Attribute равным его имени. Тип в другой строке с тем же ID в первой колонке, GUID_Type_Attribute во второй и собственно дескриптором типа в варианте.

mod
4. значения аттрибутов для объекта(id_object,id_attribute, attr_value SQL_VARIANT)
Опять же 1 к 1 - та же таблица.

mod
Вот и четыре таблицы уже... Гнусь...
Пока хватило одной...
mod
Плюс:
5. связи -(id связи, id1,id2,класс/объект,класс/объект,связь)
связь между объектами опять же тривиальна в той же таблице. Аттрибут объекта=связи. первая колонка ID объекта, вторая ID аттрибута. третья в варианте - GUID объекта на который указывает связь.

Итого получили орграф с раскрашенными ребрами в одной таблице.
Эта таблица - очень близкая аналогия модели данных Cerebrum.

mod
Вот тут вот в таблице связей приходится формулу хранить....

Да. с формулами головная боль отдельная ...
Я тебя понял конечна, но что ты этим выиграешь?
Кроме путаницы
...
Рейтинг: 0 / 0
22.09.2005, 17:12
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33284401
mod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mod
Участник
shuklin Это канечно мондяво аттрибуты нескольких разных сущностей в одном столбе хранить, а индексирвать просто супер!!! А прикинь если будут сотни тысяч записей? А как я тебе каскадное удаление делать буду?
...
Рейтинг: 0 / 0
22.09.2005, 17:15
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33284669
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
modЯ тебя понял конечна, но что ты этим выиграешь?
Кроме путаницы

Ну во первых мы получили "интересный" результат. Таблицы из 3х колонок описанной структуры достаточно чтобы представить в РМД орграф с раскрашенными ребрами, откуда следует что мы на основе этой таблички можем представить структуру любой сложности. Не знаю нафиг это полезно но интересно. Причем, заметьте, в одном поле находится ровно одно скалярное значение (типа NF).

Во вторых ента табличка интересна как очень близкий аналог модели данных низкого уровня в СУБЗ Cerebrum. Токма там на самом деле не табличка, а дерево.

В третьих, если взять СУБЗ Cerebrum то никакой особой путаницы не будет. Т.к. всеже таблицы нет (и большого колхоза, все в одном тоже), а "строки" для каждого экземпляра (одинаковые GUID в первой колонке) сгруппированы в единое целое и сопоставлены экземпляру .NET класса. Причем первой колонки нет как реализованной структуры (ее можно себе представлять если есть желание смотреть с точки зрения РМД). Первая колнока - это главный индекс "глобалей" ("hashtable"). Каждый warden-объект есть "hashtable" в которой ключами выступают ID объекта а листьями - значения аттрибутов объекта. Тоесть главный индекс это такой же объект как и все его чайлды. Аттрибут так же может быть warden и иметь субаттрибуты и т.д. Каждый узел можно рассматривать как отдельный нейрон. В итоге имеем http://www.shuklin.com/ai/ht/ru/ai00003f.aspx
...
Рейтинг: 0 / 0
22.09.2005, 18:52
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33284672
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
modshuklin Это канечно мондяво аттрибуты нескольких разных сущностей в одном столбе хранить, а индексирвать просто супер!!! А прикинь если будут сотни тысяч записей? А как я тебе каскадное удаление делать буду?

Пользуйте Cerebrum ну может не сразу, а через годок - другой.
...
Рейтинг: 0 / 0
22.09.2005, 18:53
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33284998
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
shuklinНу во первых мы получили "интересный" результат. Таблицы из 3х колонок описанной структуры достаточно чтобы представить в РМД орграф с раскрашенными ребрами, откуда следует что мы на основе этой таблички можем представить структуру любой сложности. Не знаю нафиг это полезно но интересно. Причем, заметьте, в одном поле находится ровно одно скалярное значение (типа NF).


Угу, а то жо тебя этого никто не знал, и ващще все ходили в шкурах и с дубинами.
...
Рейтинг: 0 / 0
23.09.2005, 08:19
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33285315
mod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mod
Участник
shuklin это не ново. я сам так делал (когда дейсвительно была необходимость). Но я написал проблемы. Если в твоём Cerebrum это не проблемы. То в классическом РСУБД лучше так не делать...
...
Рейтинг: 0 / 0
23.09.2005, 10:38
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33285887
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
modshuklin это не ново. я сам так делал (когда дейсвительно была необходимость). Но я написал проблемы. Если в твоём Cerebrum это не проблемы. То в классическом РСУБД лучше так не делать...

В классическом РСУБД не только это проблемы. ( вот ) в том числе и поэтому я разрабатываю собственную ООСУБД. Да в Cerebrum другие проблемы, а не это.
...
Рейтинг: 0 / 0
23.09.2005, 13:11
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33285894
shuklin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
shuklin
Участник
Gluk (Kazan)Угу, а то жо тебя этого никто не знал, и ващще все ходили в шкурах и с дубинами.
Во всяком случае уже нет отрицания тех идей которые я несу в массы ))) Прогресс однако. А отсутствие приоритета на идеи я как нибудь переживу )))
...
Рейтинг: 0 / 0
23.09.2005, 13:13
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33285905
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Блин, пророк адназначна
...
Рейтинг: 0 / 0
23.09.2005, 13:15
| Ответить | Цитировать | Написать  
Обектную СУБД
    #33290288
mod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mod
Участник
не пророк, а шаман скорее...
...
Рейтинг: 0 / 0
27.09.2005, 11:46
| Ответить | Цитировать | Написать  
18 сообщений из 68, страница 3 из 3
  3  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Обектную СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]