Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
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 отличных от нуля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2005, 00:13 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> Вообще ваше мнение о современных объектных системах неправильное по многим пунктам. http://synthesis.ipi.ac.ru/synthesis/publications/odmg93/html Если это соответствует действительности, то я рад, что у меня с Вашей точки зрения неправильное мнение о современных объектных системах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2005, 01:03 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
vybegalloХотелось бы увидеть результаты при числе physical reads отличных от нуля. Только для Вас, с "нуля", после запуска сервера Исходные запросы Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Самый первый запуск после заполнение данными и создания view Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. После полного перезапуска компьютера Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. P.S. Можете просмотреть скрипт, вдруг наврал где, хотя вряд ли ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2005, 03:07 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
vybegalloПредупреждение: проверять на Pentium133 - 32MB не буду и не просите :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2005, 03:19 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
vybegalloОграничил память MSSQL до 32МБ Холодный запуск Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2005, 12:06 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, недавно заглянул, возможно ответ заинтересует автора топика. Есть такие системы, и стоят они примерно под лимон баксов. Пример - пожалуйста, www.ftc.ru , это автоматизированная банковская система. На этом принципе сделано еще кое-что. Работает замечательно. Сколько в системе кода, таблиц и вьюшек никто давно уже не считал, очень и очень дофига. Реально, если для нормальной оракловой базы хватает разумного соотношения "память/диск/процессора", то для этой, для отработки объектной надстройки, процессоров надо раз в 5 больше. Кроме того, стоимость разработки всевозможных расширений к системе достаточно велика, из-за ее сложности. Разумеется, это окупается гибкостью, даже "бесхребетностью" системы, но оправданным это становится начиная с небольших размеров банка, документов (платежек) на ~3000 в день. И перестает быть оправданным на большом банке, документов на 30000 в день. При этом SUN с 10 процессорами начинает неимоверно тормозить из-за их перегрузки, а Оракл (а это крайне дубовая весчь) становится неплохо периодически перезагрузить, во избежание. Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и серверов, овчинка выделки не стоит... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2005, 15:07 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> Есть такие системы, и стоят они примерно под лимон баксов. ;)) Это формирование ценовой категории разработок? А чего не десять миллионов или сто? > то для этой, для отработки объектной надстройки, процессоров надо раз в 5 больше. Значит, она плохо спроектирована или плохо реализована. > Кроме того, стоимость разработки всевозможных расширений к системе > достаточно велика, из-за ее сложности. Скорее, все-таки плохо спроектирована. > Короче, разрабатывать подобные системы ИМХО неправильно для небольших баз и > серверов, овчинка выделки не стоит... Imho ошибочная точка зрения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2005, 16:51 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
;)) Это формирование ценовой категории разработок? А чего не десять миллионов или сто? Нет, это цена лицензии на 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 ошибочная точка зрения. Ну, практика-критерий истины. Если это поможет Вам заработать больше $$ чем в отсутствии подобных наворотов, то я согласен :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 18:02 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> Нет, это цена лицензии на 1 сервер. Продажи идут успешно. Почему не 10 и не > 100 - не знаю, наверное это вопрос к маркетологам :-) Понятно. Не думаю, что в данном случае цена обусловлена структурой данных. > Ну.... Один транслятор собственного объектно-ориентированного языка чего стоит. Хм... мсье безусловно понимает толк в извращениях. ;) > А насчет реализации и проектирования - насколько хорошо можно все сделать > если систему писали десятки человек много лет? Десятки человек много лет писали нечто, что в результате жутко тормозит и "...стоимость разработки расширений к системе достаточно велика...". Может, в консерватории что-то подправить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2005, 18:24 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
skorohod2 quot vybegallo > А я вот для себя сформулировал "закон сохранения сложности", который > гласит : "сложность задачи состоит из сложности алгоритмов и сложности > структур данных. Уменьшение одной компоненты ведет к увеличению другой". > > Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы > уменьшаете, но вот алгоритмы... > Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя". > Ему не хочется хвататься грязными руками за хрустальную мечту его > программистского детства :-). В конце концов, знатоки Фокса не обязаны > знать SQL ! > Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте, > прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем > хранилище. > Или вы тоже на Фоксе пишите ? Уважаемый! А можно мне поинтересоваться целью Вашего присутствия в этом топике? Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :) Объяснитесь, плиз! Очень хочется узнать! Не дочитал топик до конца (не утерпел). Что ли здесь Вашу конкрентную проблему обсуждают, уважаемый? Изначально вопрос не стоял, как Вам практически пройти по уже явно выбранному Вами пути. Это - заводите свой топик и болтайте сколько влезет. Тогда мнения, с Вами не согласные (т.е., конечно же, неправильные), Вы можете оттуда гнать поганой метлой. А пока мне лично хотелось бы узнать все ЗА и ПРОТИВ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 15:15 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Витал skorohod2 quot vybegallo > А я вот для себя сформулировал "закон сохранения сложности", который > гласит : "сложность задачи состоит из сложности алгоритмов и сложности > структур данных. Уменьшение одной компоненты ведет к увеличению другой". > > Поэтому если вы 50-100-200 таблиц собираете в 5, то сложность данных вы > уменьшаете, но вот алгоритмы... > Ну ладно, adisk не хочет попробовать написать JOIN для "объектного слоя". > Ему не хочется хвататься грязными руками за хрустальную мечту его > программистского детства :-). В конце концов, знатоки Фокса не обязаны > знать SQL ! > Но вы-то собираетесь все это реально внедрять ? Ну так попробуйте, > прикиньте, как будет выглядеть запрос с соединением 2 таблиц в вашем > хранилище. > Или вы тоже на Фоксе пишите ? Уважаемый! А можно мне поинтересоваться целью Вашего присутствия в этом топике? Задавить всех интересующихся Вашим богатым опытом? Или доказать, что этого в природе не существует и сделать такое в принципе невозможно? Или, что это не нужно Вам в Вашей тяжелой работе? Или может Вы беспокоитесь за ухудшение состояния нашей психики в ходе обсуждений? :) Объяснитесь, плиз! Очень хочется узнать! Не дочитал топик до конца (не утерпел). Что ли здесь Вашу конкрентную проблему обсуждают, уважаемый? Изначально вопрос не стоял, как Вам практически пройти по уже явно выбранному Вами пути. Это - заводите свой топик и болтайте сколько влезет. Тогда мнения, с Вами не согласные (т.е., конечно же, неправильные), Вы можете оттуда гнать поганой метлой. А пока мне лично хотелось бы узнать все ЗА и ПРОТИВ. :) Сорри! Не понял - в чей огород камень? Если в мой - так дочитайте топик до конца! Если есть претензии или вопросы - пишите, только не сюда (не надо тему засорять постами "сам дурак"). "Разбираться" со мной можно и по почте, чего не скажешь об уважаемом vybegallo. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 18:47 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Некий промежуточный (надеюсь) ответ по самому первому вопросу этой темы. Фактически - собрал ссылки в этом топике и других местах, и на то, что успел посмотреть (нумерация продуктов случайная), даю краткое резюме: ИС на ОРБД: 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 ……. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2005, 19:04 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
R2D2 Открытый (OpenSource) Написан на CLIP (http://www.itk.ru/) Кросплатформенный ОО модель поверх РБД. http://www.itk.ru/r2d2/index.shtml ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 10:07 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 11:14 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! На обсуждение набрел через ключевые слова "Иерархическая классификация". Как не программист, мало чего понял из сказанного; по ощущениям же - "очень тепло". Вчера встречался с академиком (философия, математика, теория систем), по его утверждению "более-менее стройной теории классификации не существует и толком не разрабатывается". При этом я вижу, что движение к иерархическому классификатору (ИК) идет повсеместно - но пока не стало всеобщей идеей. Обсуждаемая здесь возможность сделать ИК надстройкой над СУБД мне кажется крайне продуктивной 1. Правильно ли я понял, что применение ИК-надстройки резко повышает требования к ресурсам? Ведь достаточно один раз привязать ID записи СУБД к ID конечной ветви визуализатора 2. Не являются ли упомянутые участниками сложности следствием абстрактности обсуждаемого вопроса? Введение границ применения могло бы сильно все упростить. 3. Означают ли попытки участников написать собственный инструмент ИК то, что готовых многофункциональных древопостроителей нет на рынке? Я встречал самоделки, местами довольно остроумные; видел готовые управленческие продукты с применением классификатора в их составе - но не как отдельного продукта Темой ИК заинтересовался приличный инвестор, предполагается создание лаборатории разработки прототипов. Я - идеолог и постановщик, руководитель проекта. Предлагаю обменяться материалами, по которым можно судить, насколько Вы продвинулись в плане ИК. Поскольку я не программер - лучше короткие описания в любом виде и скриншоты. Авось из этого что-то да и выйдет - ведь при прототипировании необязательно всем сидеть в одной комнате. С уважением, Шустер Михаил Михайлович Директор по качеству Институт поддержки эксплуатации АЭС Киев shuster@npp-osi.kiev.ua PS. Материалы, раскрывающие идеи до такой степени, что их можно украсть, лучше оставить при себе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 14:54 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
А этот топик не про иерархические классификаторы. Он про объектные СУБД. Давайте заведем парочку топиков про классификаторы (можно и про графы вообще ), и поконкретнее сформулируем вопросы. "пока вы смотрите свой телевизор, инопланетяне через него трахают вам мозги" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 15:10 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Dogen (Доген), как дзенский учитель, никогда не отделял вопрос от спрашивающего :-) У меня не столь вопрос, сколь предложение. Два из трех вопросов довольно конкретны. Насчет офтопика-наберите в любом поисковике "ИК" - 80% ссылок будет на этот топик. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 15:36 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> Вчера встречался с академиком (философия, математика, теория систем), по его > утверждению "более-менее стройной теории классификации не существует и > толком не разрабатывается". Напрасно так думает Ваш академик. Поищите в google "тезаурус" и лингвистические разработки на его основе. > При этом я вижу, что движение к иерархическому классификатору (ИК) идет > повсеместно - но пока не стало всеобщей идеей. Иерархическая классификация сама по себе не представляет интереса. Это всего лишь способ хранения данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 16:00 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Тезаурус, семантика, онтология, семиотика, таксономия, фракталы - все это лишь частные применения ИК ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 16:26 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Dogen А этот топик не про иерархические классификаторы. Он про объектные СУБД. .............. Поправочка небольшая: Этот топик про ОБЪЕКТНЫЕ надстройки над РЕЛЯЦИОННЫМИ СУБД. А Объектные СУБД - это немножко совсем-совсем другое! И, как пример, то, что писал о продуктах Versant Corporation Alexey Rovdo ............... ОО модель с хранением данных в ООСУБД ОО модель поверх MS SQL, Oracle, DB2 (FastObjects SQL Object Factory) ............... укладывается в тему топика только в части последней приведенной строки! Очень "долгое" сравнение РСУБД, ООСУБД и ОРСУБД есть в форуме "Сравнение СУБД" - почитайте! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 17:18 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
skorohod Dogen А этот топик не про иерархические классификаторы. Он про объектные СУБД. .............. Поправочка небольшая: Этот топик про ОБЪЕКТНЫЕ надстройки над РЕЛЯЦИОННЫМИ СУБД. А Объектные СУБД - это немножко совсем-совсем другое! Не суть важно для прикладного программирования. Как пример можно взять Zope - у него есть объектная ZODB, но можно адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты хранить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 17:23 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
> Тезаурус, семантика, онтология, семиотика, таксономия, фракталы - все это > лишь частные применения ИК Хм... и что из этого следует? Ваша фраза "...по его утверждению "более-менее стройной теории классификации не существует и толком не разрабатывается"..." может создать у читающих неправильное представление о существующем положении вещей. Теория классификации существует и вполне себе разрабатывается. Например, в лингвистике. Более того, следующий этап развития Сети imho и будет заключаться в распространении именно семантических конструкций. Так что Ваше замечание мне не очень понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 17:45 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
2 Dogen > Не суть важно для прикладного программирования. > Как пример можно взять Zope - у него есть объектная ZODB, но можно > адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты > хранить. Ну не знаю... Изначально вопрос стоял довольно конкретный "какие вы знаете...?". На него были конкретные ответы, и кроме них попутно выяснялось много сопутствующих моментов. Просто у меня сложилось свое личное мнение на один из сопутствующих вопросов - кому нужны эти "Объектные надстройки над реляционными СУБД". Я думаю, что он интересуют тех людей, которые в силу разных обстоятельств своей профессиональной деятельности пришли к выводу, что стандартная методика проектирования и разработки ИС на основе РСУБД их уже не удовлетворяет, а про ООСУБД они или: 1) не знают совсем; 2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам; 3) знают очень хорошо и поняли, что это тоже "не то" и сознательно не хотят их использовать; Так вот я считаю, что поднимаемые в обсуждении этого топика вопросы интересны в основном именно людям "3)" и наверно "2)". Т.е. тем, кто не хочет/может переходить на новый инструмент разработки, а хочет по максимуму использовать годами наработанный опыт работы с РСУБД на несколько более высоком (логическом) уровне. P.S. Как я уже сказал - это мое личное мнение, так что если на Ваш взгляд я ошибаюсь - плз. не кидайте камни и тухлые помидоры :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 17:47 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
skorohod2 Dogen > Не суть важно для прикладного программирования. > Как пример можно взять Zope - у него есть объектная ZODB, но можно > адаптировать его и к mySQL или Oracle, будет он в RDBMS свои объекты > хранить. Ну не знаю... Изначально вопрос стоял довольно конкретный "какие вы знаете...?". На него были конкретные ответы, и кроме них попутно выяснялось много сопутствующих моментов. Просто у меня сложилось свое личное мнение на один из сопутствующих вопросов - кому нужны эти "Объектные надстройки над реляционными СУБД". Я думаю, что он интересуют тех людей, которые в силу разных обстоятельств своей профессиональной деятельности пришли к выводу, что стандартная методика проектирования и разработки ИС на основе РСУБД их уже не удовлетворяет, а про ООСУБД они или: 1) не знают совсем; 2) знают (в разной степени хорошо) и хотят их использовать но НЕ МОГУТ - по финансовым, корпоративным или каким-либо другим причинам; 3) знают очень хорошо и поняли, что это тоже "не то" и сознательно не хотят их использовать; Так вот я считаю, что поднимаемые в обсуждении этого топика вопросы интересны в основном именно людям "3)" и наверно "2)". Т.е. тем, кто не хочет/может переходить на новый инструмент разработки, а хочет по максимуму использовать годами наработанный опыт работы с РСУБД на несколько более высоком (логическом) уровне. P.S. Как я уже сказал - это мое личное мнение, так что если на Ваш взгляд я ошибаюсь - плз. не кидайте камни и тухлые помидоры :) С моей дремучей точки зрения не суть важно, разработаете Вы объектную надстройку над РСУБД или же объекты у Вас будут существовать в клиентском приложении, и на низком уровне реализации, в методах объектов, там будет код, помещающий/считывающий данные в РСУБД. Получается вопрос - никакой. В философском смысле, конечно. Ясно что на практике надо выбирать, _как_ именно лучше сделать. Но готовая объектная надстройка мне не нужна, т.к. пользы никакой с нее не вижу. Потому что я не занимаюсь иерархиями объектов. А кто занимается, они идут имхо по одному из мной указанных путей. И есть еще и такие, которые делают объектные СУБД. Надо бы с уровнем абстракции определиться, где будем про объекты говорить - на уровне приложения, промежуточной софтины о которой топик, или на уровне СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 17:56 |
|
||
|
Объектная надстройка над релационной СУБД
|
|||
|---|---|---|---|
|
#18+
Объектная надстройка может выглядеть в виде ИК, причем это не способ хранения данных, а метод визуализации их местонахождения. Посмотрел несколько тезаурусов. Душераздирающее зрелище, как говорил ослик Иа ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.01.2005, 18:02 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32889847&tid=1545998]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
61ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 410ms |

| 0 / 0 |
