Как вы пишете свои приложения, чтобы быть независимыми от базы данных?

Question

Мой начальник просит меня написать только ANSI SQL, чтобы сделать его независимым от базы данных. Но я понял, что это не так просто, как отсутствие базы данных, полностью совместимой с ANSI SQL. Код SQL редко переносится между системами баз данных без изменений.

Я видел, как люди делают разные способы сделать свою базу данных программ независимой. Например:

1. Вывести операторы SQL в файлы ресурсов.
2. Напишите класс многих провайдеров для поддержки разных баз данных.
3. Пишите только простой SQL и держитесь подальше от расширенных функций / объединений.

Вы всегда пишете свой код "любая база данных готова"? Или делать это только при необходимости? Если да, как вы этого добьетесь?

Answer 1

Вы можете использовать один из многих инструментов Object / Relational Mapper, таких как Hibernate / NHibernate, LLBLGen и так далее. Это может дать вам длинный путь к переносимости базы данных. Независимо от того, что вы делаете, у вас должен быть какой-то уровень абстракции между вашей моделью и остальным кодом. Это не означает, что вам нужна какая-то инфраструктура внедрения зависимостей, но хороший ОО-дизайн может сделать вас довольно далеко. Кроме того, придерживаться простого SQL и думать, что вы получите мобильность, довольно наивно. Это было бы верно, если бы ваше приложение было тривиальным и использовало только очень тривиальные запросы.

Что касается всегда написания приложения, которое "готово к любой базе данных", я обычно использую какой-то уровень абстракции, поэтому нетрудно перейти от одной системы баз данных к другой. Однако во многих случаях это не требуется, вы разрабатываете для платформы Oracle, SQL Server или MySQL что угодно, поэтому вам не следует жертвовать преимуществами выбранной вами СУБД только ради возможности абсолютно плавного перехода. Тем не менее, если вы создаете хороший уровень абстракции, даже нацеливание на конкретную RDBMS не обязательно будет слишком трудным для миграции на другую RDBMS.

Answer 2

Чтобы отделить ядро ​​базы данных от вашего приложения, используйте уровень абстракции базы данных (также уровень доступа к данным или DAL). Вы не упомянули, какой язык используете, но есть хорошие библиотеки абстракции базы данных для всех основных языков.

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

Answer 3

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

Что интересно, так это то, что ценность бизнеса должна поддерживаться этим требованием. Кажется, что очевидным кандидатом является то, что код базы данных должен быть готов для работы на других движках базы данных, чем текущий. Если это так, то это должно быть указано в требовании.

Оттуда вам, как инженеру, предстоит выяснить различные способы достижения этого. Можно написать ANSI SQL. Можно использовать слой абстракции базы данных.

Кроме того, вы обязаны сообщить своему боссу, какова стоимость различных альтернатив (с точки зрения производительности, скорости разработки и т. Д.).

"Написать ANSI SQL" ... га!

Answer 4

Только для записи. В Stackoverflow есть похожий вопрос:

Разработка базы данных для приложений, не зависящих от базы данных

Answer 5

Быть на 100% совместимым с ANSI SQL - сложная задача, но в любом случае она не гарантирует мобильность. Так что это искусственная цель.

Предположительно, ваш начальник просит об этом, чтобы упростить и ускорить переключение брендов баз данных для каких-то гипотетических целей в будущем (что на самом деле может и не прийти). Но он торгует этой будущей эффективностью ради большего объема работы сейчас, поскольку сделать код нейтральным к базе данных труднее. ^*

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

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

В любом случае, даже если в настоящее время вы поддерживаете только одну марку, безусловно, есть случаи, когда у вас есть выбор для кодирования некоторого SQL-кода с использованием проприетарных функций, но также существует более портативный способ достижения того же результата. Вы можете относиться к ним как к «низко висящим фруктам», и вы можете упростить перенос кода в будущем, если возникнет такая необходимость. Но не ограничивайте себя, используйте проприетарные решения, если они дают хорошую ценность. Возможно, добавьте примечание в комментариях, что это заслуживает рассмотрения, если / когда вам нужно сделать порт.

---

^* Я предпочитаю слово «нейтральный» вместо «агностик», когда говорю о независимости от платформы. Это позволяет избежать религиозного обертона. : -)