PHP, Python, приложение Ruby с несколькими RDBMS

Question

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

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

Простой пример использования разбиения на страницы и вставки: при использовании Oracle можно использовать подсказки FIRST_ROWS и APPEND (при необходимости). Перейдя к передовым примерам, я мог бы упомянуть о том, чтобы вложить в базу данных множество хранимых процедур/пакетов, где это имеет смысл. И это разные для каждой СУБД.

Используя ограниченный набор функций, обычно доступных для многих РСУБД, нельзя использовать возможности, предлагаемые этими дорогостоящими и продвинутыми СУБД.

Итак, вернемся к сути вопроса: как вы разрабатываете приложения PHP, Python, Ruby и т. Д., Которые должны запускаться на нескольких ядрах баз данных?

Мне особенно интересно узнать, как вы отделяете/используете запросы, которые специально написаны для работы на единой РСУБД. Скажем, у вас есть инструкция, которая должна работать на 3 RDBMS: Oracle, DB2 и Sql Server, и для каждого из них вы пишете отдельный оператор SQL, чтобы использовать все функции, которые может предложить RDBMS. Как ты делаешь это?

Спустив это в сторону, что вы думаете об этом пути? Стоит ли это в вашем опыте? Зачем? Почему нет?

Answer 1

Вы не можете есть торт и иметь его, выберите один из следующих вариантов.

• Используйте уровень абстракции базы данных каждый раз, когда вы можете и в тех редких случаях, когда есть необходимость ручной работы запроса (например, из соображений производительности) прилипают к наименьшему общему знаменателю и не использовать хранимые процедуры или любые проприетарные расширения, которые ваша база данных может предложить. В этом случае развертывание приложения на другой СУБД должно быть тривиальным.
• Используйте всю мощь вашей дорогой РСУБД, но учтите, что ваше приложение не будет легко переноситься. Когда возникнет такая необходимость, вам придется потратить значительные усилия на портирование и обслуживание. Разумеется, достойная многоуровневая конструкция, охватывающая все различия в одном модуле или классе, поможет в этом.

Другими словами, вы должны подумать о том, насколько вероятно, что ваше приложение будет развернуто на несколько RDBMS и сделать осознанный выбор.

Answer 2

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

Answer 3

Если вы хотите использовать колокола и свистки различных РСУБД, вы можете это сделать. Просто примените стандартные принципы OO. Выясните, какой тип API должен поддерживать ваш уровень персистентности.

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

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

Хорошей стратегией может быть реализация двух адаптеров персистентности для запуска. Предположим, вы ожидаете, что наиболее распространенным задним концом станет MySQL. Внедрите один адаптер, настроенный для MySQL. Внедрите вторую, которая использует выбранную вами библиотеку абстракции базы данных, и использует только стандартные и широко доступные функции SQL. Теперь у вас есть поддержка для множества задних концов (все зависит от выбранной вами библиотеки абстракции), плюс настраиваемая поддержка mySQL. Если вы решите, что хотите предоставить оптимизированный адаптер от Oracle, вы можете реализовать его на досуге, и вы поймете, что ваше приложение может поддерживать резервные базы данных с возможностью замены.

Answer 4

Это еще более «старомодный», чем современные ОРМ, но не ODBC решает эту проблему?