2015-03-04 2 views
5

У меня есть сценарий, когда я получаю запросы в веб-сервисе, который необходимо выполнить в базе данных.Преобразование запросов SQL Server в Postgres «на лету»

Источник этих запросов - это физическое устройство, поэтому я не могу изменить входные данные для своих запросов.

Я получаю запросы с устройства в MSSQL. Раньше бэкэнд был в SQL Server, поэтому все было довольно просто. Запросы будут поступать и выполняться как есть в БД.

Теперь мы перешли на Postgres, и нам не нужно изменять входные данные (SQL-запросы).

Что я хочу знать. Есть ли какая-либо библиотека, которая будет делать этот перевод SQL Server/T-SQL для меня, чтобы я мог запускать запросы SQL Server через это и выполнить результирующий запрос Postgres в базе данных. Я много искал, но не мог найти много, что бы это сделать. (Есть библиотеки, которые конвертируют схему из одного в другой, но мне нужно, чтобы можно было переводить запросы SQL Server в Postgres на лету)

Я понимаю, что существует немало нюансов, которые будут отличаться между SQL и postgres, поэтому между ними потребуется переводчик. Я открыт для библиотек на любом языке (который предпочтительно работает на linux:)), или если у вас есть другие предложения о том, как это сделать, также приветствуем.


Спасибо!

+4

mssql использует transact sql (TSQL) как язык .. Итак, вы ищете способ перевести tsql на pl/pgsql на лету? Быстрый Google нашел это. http://www.tpostgres.org, возможно, это поможет. что указывает на это https://bitbucket.org/openscg/pgtsql – Doon

+0

. Я считаю, что есть/были некоторые [коммерческие] попытки «адаптеров/преобразователей SQL proxy» между различными базами данных. – user2864740

+1

Запросы не являются данными, они являются кодом. Почему вы не можете их изменить? Если они распространены в коде, у вас есть серьезная проблема дизайна, которая не может быть скрыта за волшебным переводчиком. Если они были сохранены в базе данных в виде строк, конвертируйте их по одному. Также рассмотрите, что заставило вас хранить их как сырые строки вместо представлений/хранимых процедур.В общем, если вы хотите, чтобы ваш код нацелился на несколько баз данных, используйте ORM. В противном случае используйте проект базы данных, который вы можете преобразовать между продуктами, или генератор кода, который создаст целевой SQL из модели. –

ответ

0

Единственное, что я могу думать об этом может стоит попробовать SQL::Translator. Это набор модулей Perl, которые существуют уже целую вечность, но, похоже, все еще поддерживаются. Будь то то, что вы хотите, будет зависеть от того, насколько подробны эти запросы.

0

Беспроблемное решение состоит в том, чтобы сохранить SQL Server Express и ввести триггеры, которые обращаются к базе данных Postgres.

Если это слишком тяжело, вы можете посмотреть на создание шлюза табличного потока данных (TDS является сетевым транспортом SQL Server) с ограниченной функциональностью и сопоставить каждый возможный входящий запрос с любыми параметрами статическому запросу Postgres. Это ограничивает любое тестирование конечным, небольшим числом случаев.

Таким образом, SQL Server отсутствует, и у вас больше контроля, чем с помощью опции триггера.

Если ваши терминалы имеют ограниченный диалект, то это может быть практичным. Попытка общего перевода, скорее всего, будет стоить больше, чем затраты на замену устройств (если у вас уже не установлены zillions).

Существует открытая реализация FreeTDS, которую вы можете использовать, если вы довольны C или Java.

Смежные вопросы