Чтобы можно было подключаться к нескольким разным СУБД, например MSSQL, Firebird, DB2 Express C

Из тех, что знаю:


MSSQL - жду версию под Linux, в принципе все нравится, пока это лучший известный мне вариант, но к сожалению пока работает только в венде



DB2 Federation - ни разу не использовал, потому что линки в другие СУБД присутствует только в платных редакциях



Cache Intersystem - самые худшие впечатления от этого поделья с точки зрения удобства администрирования, не дай бог, когда-нибудь еще раз работать с этой гадостью. Да еще и бесплатной версии нету.


PostgreSQL - есть различные варианты линков, из проверенных читал только про Linux ODBC->DB2
еще есть SQLAlchemy (на питоне)
Perl DBI link
JDBC link

Но:

Как то мало отзывов про линк в DB2
При всем уважении к PostgreSQL, не хочется с ним связываться, потому что:

1) не нравится синтаксис команд/утилит командной строки, нравится MSSQL, DB2

2) Отрицательные отзывы про использование под большой нагрузкой типа:
https://eng.uber.com/mysql-migration/
Пишут, про баги, разрушения таблиц, потерю данных, плохую производительность
Т.е. это какой-то набор нищеброда, который можно настроить до более менее юзабельного состояния квалифицированными спецами (далеко не дешевыми).

3) 1 Це шники тоже упоминали на форумах, что PostgreSQL значительно тормознее DB2 и MSSQL в их use кейсе

Может быть, есть какой-нибудь другой удобный вариант, может быть есть поддержка в Sybase под Linux? у него есть такое в бесплатной версии?

только для легких запросов, GUI формочек, доступ из nHibernate
чтобы унифицировать, упростить программирование, не подключаться ко всем базам по отдельности

относительно тяжелые запросы могут быть только на DB2,
понятно, родными вьюхами или процедурами SQL-PL

skyANAdbtwoshnickтолько для легких запросов, GUI формочек, доступ из nHibernate
чтобы унифицировать, упростить программирование, не подключаться ко всем базам по отдельности

относительно тяжелые запросы могут быть только на DB2,
понятно, родными вьюхами или процедурами SQL-PL
А СУБД тут зачем? Обычно жеж proxy пишут, что скрывает под собой то, что запросы идут в разные хранилища.

можно и не СУБД конечно, лишь бы это было совместимо с nHibernate

Чтобы было одно соединение, смутно представляю как одна NHibernate сессия может работать с несколькими СУБД.

И по транзакции, охватывающей несколько баз, тоже вопросы, хотя пока не изучал это.

Dimitry Sibiryakovdbtwoshnickчтобы унифицировать, упростить программирование, не подключаться ко всем базам по отдельности

Тебе сюда: http://sqlrelay.sourceforge.net/


Большое спасибо! Очень походит именно на то, что нужно.

может быть, еще и аналитику посоветуете?
кубы там как в платном MSSQL, вот это все :)

желательно OpenSource тоже

наверно примерно так:

приложение -> аналитика -> SQL Relay -> разные СУБД



ну и когда без аналитиики:

приложение -> nhibernate -> SQL Relay -> разные СУБД

skyANAdbtwoshnickтолько для легких запросов, GUI формочек, доступ из nHibernate
чтобы унифицировать, упростить программирование, не подключаться ко всем базам по отдельности

относительно тяжелые запросы могут быть только на DB2,
понятно, родными вьюхами или процедурами SQL-PL
А СУБД тут зачем? Обычно жеж proxy пишут, что скрывает под собой то, что запросы идут в разные хранилища.

авторSimilarly, though SQL Relay can provide a single-point of access for multiple databases, it does not currently provide a mechanism for joining tables across databases or sending the same query to multiple databases and merging the result sets.


SQL Relay как раз оказался proxy без поддержки join

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

http://sqlrelay.sourceforge.net/documentation.html SQL Relay cannot currently translate queries from one syntax to another. Though it can be used to aim an app originally written for MySQL at Oracle, for example, it cannot (yet) transparently convert queries in MySQL syntax to Oracle syntax.


т.е. получается из одной сессии nHibernate, например с диалектом PostgreSQL для drop in replacement driver
не получится подключаться к разным СУБД через SQL Relay из-за разницы фактических диалектов СУБД?

а зачем тогд он нужен этот SQL Relay?

остается только MSSQL ...

Shtock>>остается только MSSQL .

я правильно понимаю, что слово Apache Drill ты прочитать так и не смог?

Drill это для NoSQL? я такими не пользуюсь,

у меня только YesSQL

Shtockровно как и dvl, который для этого и нужен

а разве он бесплатный?
сколько тыс USD он стоит?

Sergey OrlovМожно еще посмотреть SAP SQL anywhere, но он платный...

я для личного использования в домашних условиях ищу, поэтому пока только бесплатное

эксперименты в области SEO

Sergey Orlov,

Microsoft оказывается предоставляет бесплатную девелоперскую версию вроде как вообще без аппаратных или функциональных ограничений:
https://blogs.technet.microsoft.com/dataplatforminsider/2016/03/31/microsoft-sql-server-developer-edition-is-now-free/

для экспериментов самое оно

IBM могла бы пример взять, а не драть $2K за свою developer edition, все таки скоро появится MSSQL под Linux

Dimitry Sibiryakovdbtwoshnickскоро появится MSSQL под Linux
Они это уже второй год подряд анонсируют или третий?..


насколько я знаю, первый год,

первый раз анонсировали в начале 2016-ого официально

и обещали релиз только в середине 2017

а раньше только линуксоиды шутили на 1 апреля, к планам Microsoft эти шутки отношения не имеют

Shtock>>Drill это для NoSQL? я такими не пользуюсь,

Дрилл это для всего, просто сходи посмотри какие у него storage plugin

ни разу не работал с NoSQL базами

в Drill, действительно судя по описанию, есть возможность соединяться с JDBC источниками

а сам Drill можно подключить к какому-нибудь ORM?


типа такого:

ORM->Drill->JDBC->RDBMSes

Hibernate и nHibernate в контексте Drill не гуглятся

получается, ни мне одному приходят такие мысли:

https://community.mapr.com/thread/18598-using-drill-with-hibernate

servitМожно уточнить в чём именно это выражается и какую версию смотрели?

Файлы данных в перемешку с бинарными

Иконку светофора наверно на VB6 делали? или вообще на GWBasic

В целом очень не понравился usability их веб админки

Язык программирования mumps с его удивительным синтаксисом, который легко затмит собой Perl и 1Це вместе взятых :(

Эта ужасная консоль с 1) 2) 3) 4) ...

Судя по доке, попытка создать целую ось вместо тщательной проработки своей узкой области специализации, используя современные подходы к CLI и GUI админа.

Что-то наподобие 1Це в плане, давайте подсадим кодеров на это г, и они никуда не денутся :)
они не узнают про существование свободных и универсальных языков программирования типа Java и о СУБД с удобными интерфейсами админов, вообще их лучше запретить ибо нефиг!

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

Shtock>>ORM->Drill->JDBC->RDBMSes

дык для drill же есть odbc драйвер, поэтому
orm-jdbc-drill-rdbms

Hibernate, насколько я знаю, предполагает существование драйвера диалекта, например PostgreSQL, что было бы удобно в случае SQL Relay, если бы этот Relay умел хотя бы гетерогенные queries, желательно updatable

Не смог нагуглить не то что диалект Drill, а даже примеры его использования Drill с Hibernate.

А мне и вовсе хотелось бы nHibernate, т.е. под DotNet.

Пока искал, заметил на dice.com, что Drill сравнивают со Spark тоже Apache :)
+nHibernate +Mobius +Spark выдал сходные результаты, т.е. ничего интересного

Выяснилось, что у MS есть какой то Cosmos и что все это под кучу нод.

А мне пока более чем достаточно иметь обработчик гетерогенных запросов всего лишь на одной ноде, чем гуглить неизвестное количество времени в неизвестность с неизвестным результатом, проще использовать старый добрый Microsoft SQL, который прекрасно поддерживается в nHibernate и других популярных ORM, в т.ч. DevExpress

Shtock>>диалект Drill
sql-2003

в смысле стандарт SQL?

в Hibernate вроде каждый диалект - это частный случай SQL определенной реализации СУБД

какой конкретно то диалект подойдет?

можно пример конфигурации Hibernate для создания сессии с Drill?
а то впечатление, что одни теоретические рассуждения

на практике кто-то использует Hibernate->Drill ?
где сцылки, примеры, пруфы?

совсем не хотелось бы быть первопроходцем
настоящие герои всегда идут в обход :)

вообще предполагается использоваться примерно такой набор:

DevExpress->WinForms->MvvmFx->CSLA->nHibernate->Redis Cache->MSSQL Links->DB2->ZFS


https://stackoverflow.com/questions/982978/mvvm-for-winforms
http://cslanet.com
https://www.nuget.org/packages/NHibernate.Caches.Redis

Victor MetelitsaДаже DB2 Express-C может обращаться к другим базам (можно написать собственные врапперы или разного табличные UDF, напр., на Java или с применением OLE, обращающиеся к другой базе).

так ведь неохота, быстрее готовое использовать

Victor MetelitsaНо для приличной производительности необходимо (!), чтобы данные были в одной и той же базе (а из другой базы реплицировать; я, напр., из Оракля реплицирую самодельным репликатором). Гетерогенные запросы - это огромное зло и на них можно идти только от безысходности.

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

Victor MetelitsaHibernate, конечно, тоже тот ещё фрукт, хотя плох он даже не столько сам по себе, а тем, что пр-сты не желают разбираться, как работают СУБД и как правильно пользоваться им в свете этих знаний.
А если так нужны тормоза, можно было бы обеспечить и другим способом - ставить в нужных местах Delay(1 час) или аналог этого. А если нужно писать ещё много-много кода (построчная оплата), индусы нам показали, как его надувать.

упоминал, что nHibernate нужен для источников данных для GUI,

добавлю, что для небольших обработок над малыми сегментами данных

если на nHibernate сделать намного быстрее, чем на SQL, и главное - это отсутствие тормозов во время разработки, потому что тормозов при исполнении редактирования формочек не будет, то зачем отказываться от экономии?

и еще ORM постоянно проверяет при компиляции корректность модели, а при написании SQL коде легко ошибиться, особенно при рефакторинге

упоминал, что тяжелые запросы если и будут, то будут сделаны на DB2 SQL-PL, но их единицы

а всевозможных маленьких обработок сотни

и как тогда выгоднее сделать?