Гибернация и переносимость SQL

Я новичок в постоянстве, и я читаю книгу "Pro JPA 2". Я читал, что проблемы Java и JDBC пакета в том, что

  1. SQL не переносимый
  2. Тесная связь между кодом Java и SQL

Ирония JDBC в том, что, хотя интерфейсы программирования переносимы, язык SQL - нет. Несмотря на многочисленные попытки стандартизировать его, все еще редко пишется SQL любой сложности, который будет работать без изменений на двух основных платформах баз данных. Даже в тех случаях, когда диалекты SQL похожи, каждая база данных работает по-разному в зависимости от структуры запроса, что в большинстве случаев требует настройки конкретного поставщика.

Мои вопросы:

  1. Неужели проблема, связанная с переносимостью SQL, все еще так важна?
  2. Как я понимаю, Hibernate, TopLink и другие фреймворки также должны создавать SQL-запросы из своих метаданных (аннотаций). Как они решают проблему, связанную с переносимостью SQL?
  3. Тесная связь Java и JDBC означает, что разработчик должен писать SQL-запросы. Я правильно понимаю?

Заранее благодарен за ваши ответы)

Источник

2 ответа

Решение

  1. Да, проблема заключается в тесной связи между SQL и кодом и очень важна для проекта, потому что если нам нужно перейти с одной базы данных на другую без ORM, нам нужно изменить все запросы в приложении.

  2. Hibernate, TopLink и другие решения ORM преобразуют ваш Java-код в SQL-запросы и запускают их в базу данных, но они более стандартны и хорошо протестированы, поэтому вместо непосредственной работы с запросами мы можем положиться на инструменты ORM, которые преобразуют наш код в запросы и отвлекает нас от сложности. Поэтому рекомендуется использовать инструменты ORM вместо непосредственного написания запросов.

  3. Да, тесная связь Java и JDBC означает, что разработчик должен писать запросы SQL напрямую, которые не являются переносимыми, и в случае изменения уровня базы данных вам нужно изменить все запросы. Вместо этого, если вы используете решения ORM, вы можете перейти на любую базу данных, поддерживаемую ORM напрямую, просто изменив некоторые XML-файлы или файлы конфигурации.

Источник

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

Легко думать, что вы никогда не переключитесь, но это может быть дорогостоящим. Я принимал участие в проектах, в которых предполагалось, что база данных всегда будет поставщиком x, но позже понадобилась база данных поставщика. Чтобы приложение работало с обеими базами данных, потребовалось немало болезненных, утомительных переделок.

Я рекомендую всегда использовать стандартный SQL и / или использовать инструмент ORM, который пишет только стандартный SQL.

Мой ORM, sormula, всегда создает стандартный SQL. Если вы разработали приложение с помощью sormula, все, что требуется для переключения баз данных, - это изменить jdbc jar.

Источник
Другие вопросы по тегам