powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
25 сообщений из 438, страница 14 из 18
Объектная надстройка над релационной СУБД
    #32878274
vybegallo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ChA vybegalloПросим, просим !
Приведенные результаты были получены на Informix 9.21 на Сан боксе Solaris 8, 2 CPU 336MHz
Ловите :) Ничего лишнего, вроде более-менее адекватный перевод
Итак MSSQL 2000 SP3 на FS PRIMERGY C200, 2*1.26Гц, no parallelism

...
-- Table 'data_i'. Scan count 3, logical reads 5147, physical reads 0, read-ahead reads 0.
-- Table 'data_dc'. Scan count 1, logical reads 3021, physical reads 0, read-ahead reads 0.
-- Table 'data_c'. Scan count 1, logical reads 2093, physical reads 0, read-ahead reads 0.
-- Table 'data_dt'. Scan count 1, logical reads 3098, physical reads 0, read-ahead reads 0.
-- Table 'data_s'. Scan count 1, logical reads 487, physical reads 0, read-ahead reads 0.
--
-- SQL Server Execution Times:
-- CPU time = 6407 ms, elapsed time = 6538 ms.
[/src]Маленькая путаница произошла при переводе, там где id_p - читать id_s, махнул не глядя :) Собственно, важно соотношение
CPU time = 1640 ms, elapsed time = 1768 ms
к
CPU time = 6407 ms, elapsed time = 6538 ms.
Как видим, далеко от 30-60 раз, при этом практически не озабочивались оптимизацией.
Резюм: MS SQL 2000 лучше подходит при построении объектной настройки над реляционной СУБД, чем Informix 9.21 :)

Хотелось бы увидеть результаты при числе physical reads отличных от нуля.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32878294
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Вообще ваше мнение о современных объектных системах неправильное по многим пунктам.

http://synthesis.ipi.ac.ru/synthesis/publications/odmg93/html

Если это соответствует действительности, то я рад, что у меня с Вашей точки зрения неправильное мнение о современных объектных системах.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32878323
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vybegalloХотелось бы увидеть результаты при числе physical reads отличных от нуля.
Только для Вас, с "нуля", после запуска сервера
Исходные запросы
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
select c.id
, c.descr
, sum(cost)
from customer c, [order] o
where c.id = o.customer_id
and flag = 'Y'
and [date] between '20040101' and '20041231'
group by c.id, c.descr


select vcustomers.customer_id, customer_desc , sum(order_cost) from vcustomers, vorders
where vcustomers.customer_id = vorders.customer_id
and order_flag = 'Y'
and order_date between '20040101' and '20041231'
group by vcustomers.customer_id, customer_desc

Самый первый запуск после заполнение данными и создания view
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL Server parse and compile time: 
   CPU time =  12078  ms, elapsed time =  14385  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  1 , read-ahead reads  433 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  261 , read-ahead reads  6620 .

SQL Server Execution Times:
   CPU time =  1563  ms,  elapsed time =  3091  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  257 , read-ahead reads  4215 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  202 , read-ahead reads  1808 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  112 , read-ahead reads  888 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  197 , read-ahead reads  1791 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  16 , read-ahead reads  409 .

SQL Server Execution Times:
   CPU time =  6609  ms,  elapsed time =  8677  ms.
Затем сразу второй запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL Server parse and compile time: 
   CPU time =  0  ms, elapsed time =  0  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  0 , read-ahead reads  0 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  0 , read-ahead reads  0 .

SQL Server Execution Times:
   CPU time =  1531  ms,  elapsed time =  1699  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  0 , read-ahead reads  8 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  0 , read-ahead reads  0 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  0 , read-ahead reads  8 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  0 , read-ahead reads  0 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  0 , read-ahead reads  0 .

SQL Server Execution Times:
   CPU time =  6438  ms,  elapsed time =  6555  ms.
Ну не виноват SQL Server, что оперативки много :) После первого запроса он сожрал 254 МБ и успокоился. Диски SCSI, как полагается, 10000 об, U160. Никакого параллелизма, 1 процессор на запрос.
После полного перезапуска компьютера
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SQL Server parse and compile time: 
   CPU time =  1312  ms, elapsed time =  1448  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  1 , read-ahead reads  433 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  2 , read-ahead reads  7716 .

SQL Server Execution Times:
   CPU time =  1610  ms,  elapsed time =  2528  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  4 , read-ahead reads  5408 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  2 , read-ahead reads  3150 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  2 , read-ahead reads  2222 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  2 , read-ahead reads  3108 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  4 , read-ahead reads  485 .

SQL Server Execution Times:
   CPU time =  6546  ms,  elapsed time =  7401  ms.
SQL Server parse and compile time: 
   CPU time =  0  ms, elapsed time =  0  ms.
Далее, как упоминалось. Не верите ? Вот и я не поверил, когда было озвучено 30-60 раз и время больше часа... :)

P.S. Можете просмотреть скрипт, вдруг наврал где, хотя вряд ли ?
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32878324
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vybegalloПредупреждение: проверять на Pentium133 - 32MB не буду и не просите :)
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32878421
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vybegalloОграничил память MSSQL до 32МБ
Холодный запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
-- SQL Server parse and compile time: 
--    CPU time = 1328 ms, elapsed time = 1362 ms.
-- 
-- Table 'customer'. Scan count 1, logical reads 434, physical reads 1, read-ahead reads 433.
-- Table 'order'. Scan count 1, logical reads 7695, physical reads 2, read-ahead reads 7716.
-- 
-- SQL Server Execution Times:
--    CPU time = 1390 ms,  elapsed time = 3613 ms.
-- 
-- Table 'data_i'. Scan count 3, logical reads 5147, physical reads 4, read-ahead reads 5409.
-- Table 'data_dc'. Scan count 1, logical reads 3021, physical reads 2, read-ahead reads 3150.
-- Table 'data_c'. Scan count 1, logical reads 2093, physical reads 2, read-ahead reads 2222.
-- Table 'data_dt'. Scan count 1, logical reads 3098, physical reads 2, read-ahead reads 3108.
-- Table 'data_s'. Scan count 1, logical reads 487, physical reads 4, read-ahead reads 485.
-- 
-- SQL Server Execution Times:
--    CPU time = 6391 ms,  elapsed time = 10173 ms.
Следующий запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
-- SQL Server parse and compile time: 
--    CPU time = 1313 ms, elapsed time = 1324 ms.
-- 
-- Table 'customer'. Scan count 1, logical reads 434, physical reads 1, read-ahead reads 433.
-- Table 'order'. Scan count 1, logical reads 7695, physical reads 2, read-ahead reads 7716.
-- 
-- SQL Server Execution Times:
--    CPU time = 1515 ms,  elapsed time = 2448 ms.
-- 
-- Table 'data_i'. Scan count 3, logical reads 5147, physical reads 3, read-ahead reads 5409.
-- Table 'data_dc'. Scan count 1, logical reads 3021, physical reads 2, read-ahead reads 3150.
-- Table 'data_c'. Scan count 1, logical reads 2093, physical reads 2, read-ahead reads 2222.
-- Table 'data_dt'. Scan count 1, logical reads 3098, physical reads 2, read-ahead reads 3108.
-- Table 'data_s'. Scan count 1, logical reads 487, physical reads 4, read-ahead reads 485.
-- 
-- SQL Server Execution Times:
--    CPU time = 6453 ms,  elapsed time = 10060 ms.
Третий запуск
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SQL Server parse and compile time: 
   CPU time =  1313  ms, elapsed time =  1351  ms.

Table 'customer'. Scan count  1 , logical reads  434 , physical reads  1 , read-ahead reads  433 .
Table 'order'. Scan count  1 , logical reads  7695 , physical reads  2 , read-ahead reads  7716 .

SQL Server Execution Times:
   CPU time =  1609  ms,  elapsed time =  2518  ms.

Table 'data_i'. Scan count  3 , logical reads  5147 , physical reads  3 , read-ahead reads  5409 .
Table 'data_dc'. Scan count  1 , logical reads  3021 , physical reads  2 , read-ahead reads  3150 .
Table 'data_c'. Scan count  1 , logical reads  2093 , physical reads  2 , read-ahead reads  2222 .
Table 'data_dt'. Scan count  1 , logical reads  3098 , physical reads  2 , read-ahead reads  3108 .
Table 'data_s'. Scan count  1 , logical reads  487 , physical reads  4 , read-ahead reads  485 .

SQL Server Execution Times:
   CPU time =  6469  ms,  elapsed time =  9945  ms.
Хватит проверок ?
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32880284
Astron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте, недавно заглянул, возможно ответ заинтересует автора топика.
Есть такие системы, и стоят они примерно под лимон баксов. Пример - пожалуйста, www.ftc.ru , это автоматизированная банковская система. На этом принципе сделано еще кое-что. Работает замечательно. Сколько в системе кода, таблиц и вьюшек никто давно уже не считал, очень и очень дофига. Реально, если для нормальной оракловой базы хватает разумного соотношения "память/диск/процессора", то для этой, для отработки объектной надстройки, процессоров надо раз в 5 больше. Кроме того, стоимость разработки всевозможных расширений к системе достаточно велика, из-за ее сложности. Разумеется, это окупается гибкостью, даже "бесхребетностью" системы, но оправданным это становится начиная с небольших размеров банка, документов (платежек) на ~3000 в день. И перестает быть оправданным на большом банке, документов на 30000 в день. При этом SUN с 10 процессорами начинает неимоверно тормозить из-за их перегрузки, а Оракл (а это крайне дубовая весчь) становится неплохо периодически перезагрузить, во избежание. Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и серверов, овчинка выделки не стоит...
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32880645
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Есть такие системы, и стоят они примерно под лимон баксов.

;)) Это формирование ценовой категории разработок? А чего не десять миллионов или сто?

> то для этой, для отработки объектной надстройки, процессоров надо раз в 5 больше.

Значит, она плохо спроектирована или плохо реализована.

> Кроме того, стоимость разработки всевозможных расширений к системе
> достаточно велика, из-за ее сложности.

Скорее, все-таки плохо спроектирована.

> Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и
> серверов, овчинка выделки не стоит...

Imho ошибочная точка зрения.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32883133
Astron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
;)) Это формирование ценовой категории разработок? А чего не десять миллионов или сто?

Нет, это цена лицензии на 1 сервер. Продажи идут успешно. Почему не 10 и не 100 - не знаю, наверное это вопрос к маркетологам :-)


Значит, она плохо спроектирована или плохо реализована.
Скорее, все-таки плохо спроектирована.

Ну.... Один транслятор собственного объектно-ориентированного языка чего стоит. Транслирует свой язык в оракловый PL/SQL. А поскольку все нормализовано до упора, то каждая выборка объекта преобразуется в жуткого вида запрос, состоящий из кучи таблиц да еще и соединения все внешние. Я знакомому в свое время писал
-------------------------------------------
Astron, 28.05.2004 12:03 :
это надо видеть..... Голый оракл как в инверсии (правильно?) рядом с этим монстром просто как полено выглядит. например в нашем коде - поиск банка для вставки в плательщика
код на ее языке -
----------------
cl:=' р/с '||d_send.ACC_PL||' с '||::[CL_BANK_N]([BIC]=d_send.BIC_PL and rownum <>2).[NAME];
-----------------
транслируется в
--# 773,4
begin
select a1.id
into plp$ID_7
from Z#CL_BANK_N a1
where a1.C_BIC = D_SEND.BIC_PL and ROWNUM <> 2;
exception
when NO_DATA_FOUND then raise rtl.NO_DATA_FOUND;
when TOO_MANY_ROWS then raise rtl.TOO_MANY_ROWS;
end;
CL := ' р/с '||D_SEND.ACC_PL||' в '||Z#CL_BANK_N#INTERFACE.get_str(plp$ID_7,'NAME');
--# 774,7
-------------------------------------------
Да, можно работать напрямую, и производительность будет значительно выше, но про объекты придется забыть. А насчет реализации и проектирования - насколько хорошо можно все сделать если систему писали десятки человек много лет? Насколько уж можно.....


> Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и
> серверов, овчинка выделки не стоит...

Imho ошибочная точка зрения.
Ну, практика-критерий истины. Если это поможет Вам заработать больше $$ чем в отсутствии подобных наворотов, то я согласен :-)
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32883189
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Нет, это цена лицензии на 1 сервер. Продажи идут успешно. Почему не 10 и не
> 100 - не знаю, наверное это вопрос к маркетологам :-)

Понятно. Не думаю, что в данном случае цена обусловлена структурой данных.

> Ну.... Один транслятор собственного объектно-ориентированного языка чего стоит.

Хм... мсье безусловно понимает толк в извращениях. ;)

> А насчет реализации и проектирования - насколько хорошо можно все сделать
> если систему писали десятки человек много лет?

Десятки человек много лет писали нечто, что в результате жутко тормозит и "...стоимость разработки расширений к системе достаточно велика...". Может, в консерватории что-то подправить?
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32887305
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skorohod2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!

Не дочитал топик до конца (не утерпел).
Что ли здесь Вашу конкрентную проблему обсуждают, уважаемый? Изначально вопрос не стоял, как Вам практически пройти по уже явно выбранному Вами пути. Это - заводите свой топик и болтайте сколько влезет. Тогда мнения, с Вами не согласные (т.е., конечно же, неправильные), Вы можете оттуда гнать поганой метлой.

А пока мне лично хотелось бы узнать все ЗА и ПРОТИВ.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32887941
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Витал skorohod2 quot vybegallo

> А я вот для себя сформулировал "закон сохранения сложности", который
> гласит : "сложность задачи состоит из сложности алгоритмов и сложности
> структур данных. Уменьшение одной компоненты ведет к увеличению другой".
>
> Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы
> уменьшаете, но вот алгоритмы...
> Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя".
> Ему не хочется хвататься грязными руками за хрустальную мечту его
> программистского детства :-). В конце концов, знатоки Фокса не обязаны
> знать SQL !
> Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте,
> прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем
> хранилище.
> Или вы тоже на Фоксе пишите ?

Уважаемый!
А можно мне поинтересоваться целью Вашего присутствия в этом топике?
Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :)
Объяснитесь, плиз! Очень хочется узнать!

Не дочитал топик до конца (не утерпел).
Что ли здесь Вашу конкрентную проблему обсуждают, уважаемый? Изначально вопрос не стоял, как Вам практически пройти по уже явно выбранному Вами пути. Это - заводите свой топик и болтайте сколько влезет. Тогда мнения, с Вами не согласные (т.е., конечно же, неправильные), Вы можете оттуда гнать поганой метлой.

А пока мне лично хотелось бы узнать все ЗА и ПРОТИВ.

:) Сорри! Не понял - в чей огород камень?
Если в мой - так дочитайте топик до конца! Если есть претензии или вопросы - пишите, только не сюда (не надо тему засорять постами "сам дурак"). "Разбираться" со мной можно и по почте, чего не скажешь об уважаемом vybegallo.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32887977
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Некий промежуточный (надеюсь) ответ по самому первому вопросу этой темы. Фактически - собрал ссылки в этом топике и других местах, и на то, что успел посмотреть (нумерация продуктов случайная), даю краткое резюме:

ИС на ОРБД:

1. NEXUS
NEXUS (независимая группа разработчиков)
Россия, СПб, 2000 - 2005
http://nexus.arbinada.com/
«Open-Source», доступны инструменты разработчика, исходники, документация.
Архитектура: (2) клиент-сервер; Универсальный «тонкий» клиент - генератор интерфейса (С++); Сервер - СУБД MS SQL 2000; Предметная область, бизнес-правила, GUI и т.д. описаны в модели в виде объектов и хранятся в РБД; Методы объектов – T-SQL; Реляционная реализация объектной модели в РБД «полустатичная» (при расширении модели в БД могут добавляться таблицы);
Есть несколько успешных внедрений в коммерческих структурах (СПб) разного профиля (названы 3 компании).

2. SQ конструктор
Extracode (Экстракод), Институт Проблем Управления РАН
Россия, Москва, 2002 - 2005
http://www.s-q.ru/, http://www.extracode.ru
Коммерческая, доступны ограниченные демо-версии системы, документация.
Архитектура: (3?) стандартный вэб-клиент – вэб-сервер (IIS, Apache) – БД-сервер (MS SQL, планируется Oracle); Предметная область, бизнес-правила, GUI и т.д. описаны в модели в виде объектов и хранятся в РБД; Методы объектов – T-SQL + «картриджи» на языке программирования;
Реляционная реализация объектной модели в РБД «статичная» (при расширении модели табличный состав БД не меняется);
Есть большой набор "конфигураций" по различным бизнес-задачам, но на сайте отсутствуют упоминания о конкретных внедрениях системы.

3. UBD (УБД) – разработчиком декларируется «ООСУБД»
stikriz (компания?) (Николай Банников)
Россия, город?, 2003 - 2004
http://www.stikriz.net
Коммерческая, доступна ограниченная демо-версия системы.
Архитектура: (3) клиент – сервер приложений – сервер БД; Клиент (Delphi), сервер приложений (Delphi), сервер БД (MS SQL 2000, а также InterBase SQL Server и клоны Yaffil и FireBird); Предметная область, бизнес-правила, GUI и т.д. описаны в модели в виде объектов и хранятся в РБД; "Независимость данных пользователя от конечного хранилища данных; Доступ к данным на OSQL и на стандартном SQL92";
Методы объектов – ? (возм. Delphi?);
Реляционная реализация объектной модели в РБД - ???.
Декларируется – сделали уже очень много, и сделаем все, что вам нужно!

4. VisualDoc 4.1
«ЦентрИнвест Софт»,
Россия, Москва, 1998 – 2005
http://www.visualdoc.ru
Коммерческая, доступна полнофункциональная демо-версия (3.35) с ограничением по времени использования, документация;
Архитектура (3?); «…объектноориентированная СУБД, работающая на базе MS SQL или ORACLE, имеющая в своем составе специальные средства для работы с документами, процессами и данными, включая язык запросов VD SQL.», «…динамическое отражение изменений в (предметной области) структуре (системы) без дополнительного перепрограммирования…»;
Есть большое количество успешных внедрений в коммерческих и гос. структурах разного профиля.

5. Hibernate (Java)
Internet community (+ русскоязычные энтузиасты)
http://www.hibernate.org, http://www.hibernate.ru - неофициальный сайт.
Free / Open-Source - Hibernate is licensed under the LGPL (Lesser GNU Public License)
Доступны релизы, исходники, документация на английском, частично на русском;
Hibernate - инструмент объектно-реляционного отображения данных (ORM tool) в реляционную модель со схемой данных основанной на SQL, для Java-окружения.

6. ERP5
Internet community
http://erp5.org
Open-Source (+ free СУБД: MySQL, PostgreSQL, …)
Доступны релизы, исходники, документация на нескольких европейских языках;
«ERP5: A Next-Generation, Open-Source ERP Architecture …»

7. TechInsite
Австралия, Мельбурн 1999-2005
http://www.techinsite.com.au/tiOPF/Default.htm
Open-Source; Доступны релизы, исходники, документация на английском;
«The TechInsite Object Persistence Framework (tiOPF) is an Open Source framework of Delphi code that simplifies the mapping of an object oriented business model into a relational database...»
Архитектура 3-звенная, возможны варианты 2-звенной и много-звенной архитектуры;

Другие альтернативные коммерческие продукты:
InstantObjects
BOLD
KODO
…….
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32888526
Фотография adisk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
R2D2
Открытый (OpenSource)
Написан на CLIP (http://www.itk.ru/)
Кросплатформенный
ОО модель поверх РБД.

http://www.itk.ru/r2d2/index.shtml
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32888675
Alexey Rovdo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
FastObjects .NET, FastObjects t7
Versant Corporation (+Poet Holdings)

платформа .NET (C#, VB .NET и др. IL-совместимые языки)
платформы Win, Lin, Unix (C++, Java)
ОО модель с хранением данных в ООСУБД
ОО модель поверх MS SQL, Oracle, DB2 (FastObjects SQL Object Factory)

http://www.versant.ru
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32889490
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Здравствуйте!
На обсуждение набрел через ключевые слова "Иерархическая классификация". Как не программист, мало чего понял из сказанного; по ощущениям же - "очень тепло".
Вчера встречался с академиком (философия, математика, теория систем), по его утверждению "более-менее стройной теории классификации не существует и толком не разрабатывается". При этом я вижу, что движение к иерархическому классификатору (ИК) идет повсеместно - но пока не стало всеобщей идеей. Обсуждаемая здесь возможность сделать ИК надстройкой над СУБД мне кажется крайне продуктивной

1. Правильно ли я понял, что применение ИК-надстройки резко повышает требования к ресурсам? Ведь достаточно один раз привязать ID записи СУБД к ID конечной ветви визуализатора
2. Не являются ли упомянутые участниками сложности следствием абстрактности обсуждаемого вопроса? Введение границ применения могло бы сильно все упростить.
3. Означают ли попытки участников написать собственный инструмент ИК то, что готовых многофункциональных древопостроителей нет на рынке? Я встречал самоделки, местами довольно остроумные; видел готовые управленческие продукты с применением классификатора в их составе - но не как отдельного продукта

Темой ИК заинтересовался приличный инвестор, предполагается создание лаборатории разработки прототипов. Я - идеолог и постановщик, руководитель проекта.
Предлагаю обменяться материалами, по которым можно судить, насколько Вы продвинулись в плане ИК. Поскольку я не программер - лучше короткие описания в любом виде и скриншоты. Авось из этого что-то да и выйдет - ведь при прототипировании необязательно всем сидеть в одной комнате.

С уважением,
Шустер Михаил Михайлович
Директор по качеству
Институт поддержки эксплуатации АЭС
Киев

shuster@npp-osi.kiev.ua

PS. Материалы, раскрывающие идеи до такой степени, что их можно украсть, лучше оставить при себе.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32889544
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А этот топик не про иерархические классификаторы.
Он про объектные СУБД.
Давайте заведем парочку топиков про классификаторы (можно и про графы вообще ), и поконкретнее сформулируем вопросы.

"пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги"
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32889653
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Dogen (Доген), как дзенский учитель, никогда не отделял вопрос от спрашивающего :-)
У меня не столь вопрос, сколь предложение. Два из трех вопросов довольно конкретны.
Насчет офтопика-наберите в любом поисковике "ИК" - 80% ссылок будет на этот топик.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32889761
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Вчера встречался с академиком (философия, математика, теория систем), по его
> утверждению "более-менее стройной теории классификации не существует и
> толком не разрабатывается".

Напрасно так думает Ваш академик. Поищите в google "тезаурус" и лингвистические разработки на его основе.

> При этом я вижу, что движение к иерархическому классификатору (ИК) идет
> повсеместно - но пока не стало всеобщей идеей.

Иерархическая классификация сама по себе не представляет интереса. Это всего лишь способ хранения данных.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32889847
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Тезаурус, семантика, онтология, семиотика, таксономия, фракталы - все это лишь частные применения ИК
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32890004
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dogen
А этот топик не про иерархические классификаторы.
Он про объектные СУБД.
..............


Поправочка небольшая:
Этот топик про ОБЪЕКТНЫЕ надстройки над РЕЛЯЦИОННЫМИ СУБД.
А Объектные СУБД - это немножко совсем-совсем другое!
И, как пример, то, что писал о продуктах Versant Corporation
Alexey Rovdo
...............
ОО модель с хранением данных в ООСУБД
ОО модель поверх MS SQL, Oracle, DB2 (FastObjects SQL Object Factory)
...............

укладывается в тему топика только в части последней приведенной строки!

Очень "долгое" сравнение РСУБД, ООСУБД и ОРСУБД есть в форуме "Сравнение СУБД" - почитайте!
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32890014
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skorohod Dogen
А этот топик не про иерархические классификаторы.
Он про объектные СУБД.
..............


Поправочка небольшая:
Этот топик про ОБЪЕКТНЫЕ надстройки над РЕЛЯЦИОННЫМИ СУБД.
А Объектные СУБД - это немножко совсем-совсем другое!


Не суть важно для прикладного программирования.

Как пример можно взять Zope - у него есть объектная ZODB, но можно адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты хранить.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32890061
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Тезаурус, семантика, онтология, семиотика, таксономия, фракталы - все это
> лишь частные применения ИК

Хм... и что из этого следует?

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

Так что Ваше замечание мне не очень понятно.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32890066
skorohod
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Dogen
> Не суть важно для прикладного программирования.
> Как пример можно взять Zope - у него есть объектная ZODB, но можно
> адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты
> хранить.

Ну не знаю...
Изначально вопрос стоял довольно конкретный "какие вы знаете...?". На него были конкретные ответы, и кроме них попутно выяснялось много сопутствующих моментов.
Просто у меня сложилось свое личное мнение на один из сопутствующих вопросов - кому нужны эти "Объектные надстройки над реляционными СУБД".
Я думаю, что он интересуют тех людей, которые в силу разных обстоятельств своей профессиональной деятельности пришли к выводу, что стандартная методика проектирования и разработки ИС на основе РСУБД их уже не удовлетворяет, а про ООСУБД они или:
1) не знают совсем;
2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам;
3) знают очень хорошо и поняли, что это тоже "не то" и сознательно не хотят их использовать;
Так вот я считаю, что поднимаемые в обсуждении этого топика вопросы интересны в основном именно людям "3)" и наверно "2)". Т.е. тем, кто не хочет/может переходить на новый инструмент разработки, а хочет по максимуму использовать годами наработанный опыт работы с РСУБД на несколько более высоком (логическом) уровне.

P.S. Как я уже сказал - это мое личное мнение, так что если на Ваш взгляд я ошибаюсь - плз. не кидайте камни и тухлые помидоры :)
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32890090
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
skorohod2 Dogen
> Не суть важно для прикладного программирования.
> Как пример можно взять Zope - у него есть объектная ZODB, но можно
> адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты
> хранить.

Ну не знаю...
Изначально вопрос стоял довольно конкретный "какие вы знаете...?". На него были конкретные ответы, и кроме них попутно выяснялось много сопутствующих моментов.
Просто у меня сложилось свое личное мнение на один из сопутствующих вопросов - кому нужны эти "Объектные надстройки над реляционными СУБД".
Я думаю, что он интересуют тех людей, которые в силу разных обстоятельств своей профессиональной деятельности пришли к выводу, что стандартная методика проектирования и разработки ИС на основе РСУБД их уже не удовлетворяет, а про ООСУБД они или:
1) не знают совсем;
2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам;
3) знают очень хорошо и поняли, что это тоже "не то" и сознательно не хотят их использовать;
Так вот я считаю, что поднимаемые в обсуждении этого топика вопросы интересны в основном именно людям "3)" и наверно "2)". Т.е. тем, кто не хочет/может переходить на новый инструмент разработки, а хочет по максимуму использовать годами наработанный опыт работы с РСУБД на несколько более высоком (логическом) уровне.

P.S. Как я уже сказал - это мое личное мнение, так что если на Ваш взгляд я ошибаюсь - плз. не кидайте камни и тухлые помидоры :)

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

Получается вопрос - никакой. В философском смысле, конечно. Ясно что на практике надо выбирать, _как_ именно лучше сделать.

Но готовая объектная надстройка мне не нужна, т.к. пользы никакой с нее не вижу. Потому что я не занимаюсь иерархиями объектов.

А кто занимается, они идут имхо по одному из мной указанных путей. И есть еще и такие, которые делают объектные СУБД.

Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД.
...
Рейтинг: 0 / 0
Объектная надстройка над релационной СУБД
    #32890104
MMS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MMS
Гость
Объектная надстройка может выглядеть в виде ИК, причем это не способ хранения данных, а метод визуализации их местонахождения.
Посмотрел несколько тезаурусов. Душераздирающее зрелище, как говорил ослик Иа
...
Рейтинг: 0 / 0
25 сообщений из 438, страница 14 из 18
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Объектная надстройка над релационной СУБД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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