Досталась мне тут недавно демка одной СУБД - ObjectHaven (Производитель ObjectHaven).
Должен сказать, вещь впечатляющая:
во-первых, удобная - не нужно изучать никаких дополнительных языков - пиши себе базейки на том, какой знаешь
во-вторых, интегрируется достаточно легко (благодаря тому, что основана на COM)
в-третьих, быстрая (пробовал на локальной машине, вскорости попробую и через сеть)
ну там еще куча всякого - транзакции, многопользовательская и прочая...
Насчет компонентности приведу цитату из доки:

Цитата

СУБД ObjectHaven предназначена для управления Базами Данных, состоящими из множества взаимосвязанных COM-объектов, наделенных свойством перманентности. Хотя ObjectHaven построена по принципу объектно-ориентированных СУБД, ее реализация имеет ряд существенных отличий от традиционных ООСУБД. Важнейшим отличием ObjectHaven от ООСУБД является то, что в Базах Данных ObjectHaven хранятся COM-объекты, а не объекты какого-либо конкретного языка программирования. Это дает основание говорить об ObjectHaven как о представителе принципиально нового класса компонентно-ориентированных СУБД. ObjectHaven обеспечивает следующие преимущества: Открытость метаданных, Улучшенная совместимость, Поддержка гетерогенных сред разработки Большинство существующих ООСУБД предоставляют свои собственные средства описания метаданных БД, и связи метаданных БД с конкретными системами программирования. Так, для введения в ООСУБД поддержки такого языка программирования, как, например, C++, разработчикам ООСУБД потребуется написать комплект библиотек и утилит, обеспечивающих экспорт метаданных в файлы, содержащие исходные тексты на C++, причем скорее всего метаданные, предназначенные для экспорта в C++, будут непригодны для экспорта, например, в Pascal, и наоборот. При таком подходе не остается других разумных способов предоставления метаданных для разных систем программирования, кроме как содержание нескольких копий одних и тех же метаданных, предназначенных для экспорта в различные системы программирования, что в свою очередь требует постоянных усилий по сохранению соответствия различных версий метаданных. Соответственно поддержку нескольких языков программирования подобными ООСУБД нельзя назвать удовлетворительной для тех задач, которые требуют гетерогенную разработку. Для Баз Данных, управляемых ObjectHaven, метаданными являются обычные библиотеки типов COM, которые на сегодняшний день поддерживается всеми популярными системами программирования, ориентированными на разработку под Windows; и все СП под Windows, которые могут появиться в будущем, наверняка также будут поддерживать эту технологию. Полная инкапсуляция реализации компонентов базы данных. Совместимость версий базы данных. При обычном подходе, принятом в ООСУБД, метаданные, помимо всего прочего, хранят в себе информацию об иерархии классов перманентных объектов, их методах и членах данных. Такая подробная информация не нужна клиенту базы данных (его не должны интересовать подробности реализации объектов базы данных, ему достаточно интерфейсной части), и ограничивает гибкость модели данных. Несоблюдение принципа отделения интерфейса от реализации в типичных ООСУБД влечет да собой трудности в разработке и сопровождении программных продуктов, использующих такие ООСУБД. Например, доработка модели данных потребует доработку всех приложений, ее использующих. Использование в ObjectHaven библиотек типов COM в качестве хранилищ метаданных позволяет неукоснительно следовать принципу отделения интерфейса от реализации. Даже существенные доработки модели данных в базе данных ObjectHaven при надлежащем подходе не приведут к конфликтам версий модулей программной системы, использующей базу данных ObjectHaven, что позволит существенно сэкономить на сопровождении такой программной системы. Улучшенное повторное использование компонентов схемы БД. Возможность сборки БД из повторно используемых компонентов Эффективное повторное использование кода является розовой мечтой разработчиков ПО. Однако мечта эта на практике зачастую оказывается на удивление тяжело достижимой. Не вдаваясь в анализ причин, приведем некоторые конкретные факты: Попытки увеличить долю повторного использования кода путем организации репозиториев повторно используемого кода себя не оправдали и уже давно не популярны. Современное программное обеспечение в среднем на 70% состоит из повторно используемых компонентов, приобретенных у третьих фирм. Такие компоненты используют какую-либо относительно универсальную технологию, вроде ActiveX, и поставляются в виде исполняемых модулей, без исходных текстов. Наиболее популярные СП, такие как Delphi и VisualBasic, используют либо ActiveX, либо аналогичные технологии, либо и то и другое вместе. Очевидно, что на сегодняшний день путь к успешному повторному использованию кода лежит через задействование технологии, обеспечивающей унифицированный способ взаимодействия с повторно используемыми программными компонентами. ObjectHaven в связке с Automation и стандартизованным набором COM-интерфейсов предоставляет как раз такую технологию в приложении к базам данных. ObjectHaven позволяет сформировать целый рынок повторно используемых компонентов БД, ориентированных на применение в наиболее популярных предметных областях, и распространяемых в двоичном виде, без исходных текстов. Возможность контролировать сложность базы данных Использование СОМ предполагает проектирование схемы БД в форме набора объектов, реализующих четко определенные интерфейсы. Это позволяет абстрагироваться от деталей реализации отдельных компонентов схемы БД, сосредоточившись на проектировании интерфейсов, в результате чего схема БД становится более простой для понимания. Сокрытие реализации отдельных компонентов схемы БД обеспечивает большой "запас прочности" схемы БД относительно увеличения ее сложности, так как интерфейсы в гораздо меньшей степени подвержены изменениям, чем объекты, их реализующие. Таким образом, СУБД ObjectHaven обеспечивает стабильную основу для разработки сложных баз данных. Соблюдение в ObjectHaven принципа отделения интерфейса от реализации позволяет локализовать сложность модели данных в отдельных компонентах, благодаря чему появляется возможность постепенного, контролируемого наращивания сложности БД путем эволюционного развития ее отдельных компонентов.

Хотелось бы услышать ваше мнение по этому поводу?

Мне больше всего "Улучшенная совместимость" понравилась... Хорошее у них представление о совместимости

По этой базе мы тоже скорее всего не найдём знатоков, описание чахлое, но лучше такое, чем никакого.

угу, они бы еще хоть демку на сайте выложили

У меня в голове не совмещается COM технология и фраза о том, что она такая замечательная. Слишком много я знаю примеров, где применение COM технологии позволило вначале упростить жизнь большой команде, но потом становилось почти непреодолтмой преградой при дальнейшей модернизации системы. Да и вся архитектура COM в виндах реализована так, что не позволяет получить гарантированной "быстроты".
Интересно и как они описывают выгоды применения COM - списано один к одному из учебника по этой технологии.
Та же GTK написана на чистом C (даже не C++), но именно такая технология позволяет получить помимо скорости и простоты модернизации еще и платформенную независимость.

Цитата(NightGoblin @ 2.11.2003, 05:29)

Мне больше всего "Улучшенная совместимость" понравилась... Хорошее у них представление о совместимости

Представление о совместимости действительно хорошее. Причем без всяких кавычек. Компонентно-ориентированная СУБД ObjectHaven изначально не позиционируется как конкурент реляционным, и даже объектно-ориентированным СУБД. Поэтому совместимость с ними (типа поддержки SQL, ODBC, и т.п.) хотя и возможна, но не играет совершенно никакой роли. Играет важнейшую роль та совместимость, которая наиболее важна не разработчикам БД, а разработчикам конечных программных продуктов и их пользователям. А именно возможность интегрировать свою программу в другие популярные программы, используя их брэнды как "ледокол", пробивающий вам путь к вашим покупателям, и наоборот: дать возможность другим разработчикам заработать себе денег на усилении вашей рыночной позиции, интегрируя в вашу программу свои дополнительные компоненты.

Цитата(Vit @ 7.11.2003, 20:25)

По этой базе мы тоже скорее всего не найдём знатоков, описание чахлое, но лучше такое, чем никакого

Каждый программист, у которого есть одна голова и две руки, автоматически является специалистом по СУБД ObjectHaven . Потому, что концепция этой СУБД заключается не в том, чтобы представить рынку еще одну СУБД, а в том, чтобы дать программистам возможность писать БД точно так же, как и обычные программы. Все принципы, правила, закономерности и т.п., имеющие место при создании ПО, не взаимодействующего ни с какими БД, остаются верны и ПОЛЕЗНЫ при создании программ, базирующихся на ObjectHaven.

Цитата(cully @ 30.11.2003, 23:47)

угу, они бы еще хоть демку на сайте выложили

Все заинтересованные могут заказать Trial-версию ObjectHaven. Для этого заказывайте ее по почте: [email protected]

Цитата(DENNN @ 2.12.2003, 11:17)

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

Все успешные программные проекты похожи друг на друга. Каждый провальный проект проваливается по-своему. Анализировать причины провала программного проекта достаточно трудно еще и по тому, что в этом случае играют огромную роль сугубо личные мотивы и эмоции. Поэтому в качестве контраргумента я просто приведу несколько безусловно успешных программных продуктов, которые прекрасно эволюционируют, и при этом базируются на технологии COM: линейка MS Ofiice, MSDEV, линейка продуктов Rational (включая Rose), линейка продуктов Compuware...
Думаю, достаточно. Любой может этот список продолжить.
Что же касается проблем с производительностью приложений COM. Имею смелость напомнить, что технология DirectX, на которой сегодня основаны лучшие современные компьютерные игры (даже OpenGL постепенно начал сдавать свои позиции в этом секторе), также основана на технологии COM. Думаю, никого не нужно убеждать в том, что в этом классе ПО производительность критически важна.

Пожалуйста, задавайте вопросы по существу, и мы на них ответим на этом форуме либо на форуме нашего сайта: Форум по ObjectHaven.

Спасибо за отклик и объяснения.
Вот здесь условия описания базы данных:
http://forum.vingrad.ru/index.php?act=ST&f=53&t=14013

Если Вы опишите БД следуя указанным пунктам, то мы будем рады поместить это описание в FAQ. Как я понимаю Вы относитесь к разработчикам, поэтому прошу Вас быть максимально объективным, как известно, из авторам присуще преукрашение достоинств...

А как осуществляется работа на Linux клиенте с этой базой данных?

Цитата

А как осуществляется работа на Linux клиенте с этой базой данных?

Пока что никак, т.к. ObjectHaven под Linux еще не портировался. И вряд ли будет портироваться 1:1, т.к. в этом случае лучше будет вместо COM использовать CORBA, по крайней мере на сегодняшний день так обстоят дела с Linux.

Да, значит плохо... Вообще-то СУБД не поддерживающая клиентов на разных платформах ИМХО совершенно тупиковая ветвь... Современная архитектура опирается на то что платформа самого сервера базы данных не имеет значения - всё равно он стоит на отдельной машине и на ней ничего больше не работает, а вот клиенты должны поддерживать как минимум 5 основный осей: Win, Unix, Linux, MacOS, AS/400. В противном случае система может предоставить конкуренцию разве что MS Access...

Цитата

Да, значит плохо... Вообще-то СУБД не поддерживающая клиентов на разных платформах ИМХО совершенно тупиковая ветвь... Современная архитектура опирается на то что платформа самого сервера базы данных не имеет значения - всё равно он стоит на отдельной машине и на ней ничего больше не работает, а вот клиенты должны поддерживать как минимум 5 основный осей: Win, Unix, Linux, MacOS, AS/400. В противном случае система может предоставить конкуренцию разве что MS Access...

Вот это-как раз то, о чем я Вас предупреждал на http://forum.vingrad.ru/index.php?act=ST&f=53&t=14013. Если игнорировать информацию о том, для решения каких именно задач предназначена СУБД, можно обгадить любой, даже самый лучший в своем классе продукт.
Кстати, о современной архитектуре: Вы принимали участие хотя бы в одном программном проекте, в котором писалась сразу "пачка" толстых клиентов, по одному на каждую из перечисленных Вами ОС? Или это заключение - результат т.н. "умственного эксперимента"? Ваша "Современная архитектура" - это типичная двухслойка, морально устаревшая в нынешней программной индустрии, ориентированной на Internet, тонких клиентов и соответственно - многоуровневые архитектуры приложений. Сейчас сами клиенты БД превращаются в Web-серверы. А это значит, что конечных клиентов таких систем не парит, под управлением какой OC работает Web-сервер, и соответственно - клиент БД.
"Двухслойки" сейчас держат нишу ПО для рабочих групп. Вы знаете много рабочих групп, члены которых работают под управлением нескольких различных ОС, и при этом работают с одной и той же БД? Каков процент таких рабочих групп относительно их общего количества?
Я уже не стану говорить о локальных приложениях. Тут и так все ясно.

Не знаю процентов, я именно в такой группе работаю, причём все с кем я общаюсь работают в тех же условиях... "Тонкие клиенты"? - да иногда это выгодно, но в современных системах применение только многоуровневой архитектуры - это исключение, идеальная ситуация которая в реальной жизни встречается только в студенческих задачах. Реально, те задачи с которыми я сталкиваюсь: десятки серверов, десятки тонких клиентов, десятки толстых клиентов, тысячи конечных клиентов. Операционные системы: Win, Linux, MacOS... Взаимоствязи очень сложны, и ограничиться простой и ясной структурой как в учебнике нельзя - только блок-схемы системы включают в себя несколько листов ватмана, и если есть проблемы удалённого доступа к каким-либо элементам, то это приводит к необходимости писать лишний код, лишние сервера и тем самым снижать стабильность системы и повышать её стоимость. Те "новые" веяния в архитектуре которые Вы говорите - это не панацея и не догма, это просто очередной способ организации системы. Иногда он удобен и нужен, а иногда нет. Если программист вынужден его использовать всегда, только потому что ничего другого нет - это только потеря времени и денег, всегда надо понимать, что любой способ реализации имеет свои плюсы и минусы. Вы мне сейчас доказываете полнейшую чушь: "Это не реализовано, но это даже хорошо"...

Цитата

Вы мне сейчас доказываете полнейшую чушь: "Это не реализовано, но это даже хорошо"...

Да, это действительно хорошо, потому, что это изначально ставит программистов в известность о том, что ObjectHaven не является конкурентом Ораклу и иже с ними. Но и промышленные СУБД далеко не ко всем задачам пригодны. Соответственно и сравнивать ObjectHaven с СУБД промышленного масштаба просто глупо. Попробуйте, например, разработать коробочную версию программы - почтового клиента, который хранит письма в БД Oracle. А если напишете - попробуйте ее продать массовым тиражом по 20$ за штуку.
А вот Ваша позиция - это действительно полнейшая ахинея: "Для моих задач это не подходит. Значит это - вообще тупиковая ветвь."

Ну и как мне этот почтовый клиент сделать, если Linux не поддерживается? Какой смысл создавать такие программы как почтовый клиент, которые работают только под Windows?