#java #mysql #sql #database #oracle
#java #mysql #sql #База данных #Oracle
Вопрос:
У меня есть Java-приложение, которое должно поддерживать как MySQL, так и Oracle DBMS.
Изначально она была написана для MySQL, и по разным причинам я не использую такие фреймворки, как Hibernate и подобные, поэтому запросы написаны на «чистом» SQL, хранящемся в файлах конфигурации.
Что я видел до сих пор, так это то, что есть некоторые инструменты для автоматического преобразования из MySQL в Oracle и наоборот, такие как Razor-SQL.
Использование этого инструмента помогло мне, но теперь мне приходится поддерживать 2 разных файла для запросов, таблицы DDL и т.д. И это кошмар!
Чтобы избежать слишком большого изменения существующих запросов, я написал несколько функций PL / SQL для эмуляции функций MySQL, которые я использую чаще всего, таких как UNIX_TIMESTAMP, FROM_UNIXTIME и т.д..
Я хотел бы спросить, есть ли у кого-нибудь совет или лучший подход к решению таких проблем.
Есть ли какие-то рекомендации, которым следует следовать?
Заранее благодарю вас
Ответ №1:
В прошлом я использовал шаблоны. Подумайте об одном операторе SQL, но с шаблоном if / else в нем для поддержки разных баз данных.
например
select a,b,c
from T
where
id = ?
#if ORACLE
and oracleFunc(d,c)
#else
and MYSQLFunc(d,c)
#end
order by b
Комментарии:
1. спасибо за ваш совет, таким образом, мне пришлось бы сохранить только 1 файл, но это будет намного сложнее .. мне нужно подумать об этом 🙂
2. Действительно. Бесплатных обедов не бывает. Большинство команд, с которыми я работал, использовали синтаксис DSL для SQL, который скрывает от них различия в базе данных. например, HSQL или пользовательский синтаксис, написанный на Scala. Но тогда вы привязаны к ограничениям / кривой обучения / причудам этого DSL.
Ответ №2:
Я не знаком с различиями между oracle и MySQL, но я сделал фактически то же самое с oracle и derby.
Для многих различий (таких как получение значений из последовательностей, оконные запросы и т.д.) Я определил api на java, описывающий функциональность, и предоставил различные реализации на основе конкретного типа соединения, чтобы либо выполнить работу (например, получить значения последовательности), либо правильно собрать части sql (например, оконные запросы). Здесь рассмотрено большинство различий.
В других случаях, когда одна и та же концепция не поддерживается в обоих (например, кортеж в предложениях), я в конечном итоге управляю отдельным sql.
Комментарии:
1. Это кажется хорошей идеей, но наша ситуация такова, что мы используем старый db manager, написанный в нашей компании почти 10 лет назад, для сборки частей sql, только для MySQL. Теперь эта библиотека настолько широко используется в компании, что от нее сложно отказаться. Мы не можем переписать его, и мы не хотим добавлять новый уровень между менеджером и БД для поддержки oracle тоже.