Абстракция базы данных - поддержка нескольких синтаксисов

Question

В проекте PHP, над которым я работаю, нам нужно создать несколько расширений DAL для поддержки нескольких платформ баз данных. Основной недостаток, который у нас есть, заключается в том, что разные платформы имеют разный синтаксис - известные MySQL и MSSQL совершенно разные.

Что было бы лучшим решением для этого?

Вот пара, которую мы обсудили:

Построение SQL на основе классов

Это будет включать создание класса, который позволит вам строить SQL-запросы побитно. Например:

$stmt = new SQL_Stmt('mysql');
$stmt->set_type('select');
$stmt->set_columns('*');
$stmt->set_where(array('id' => 4));
$stmt->set_order('id', 'desc');
$stmt->set_limit(0, 30);
$stmt->exec();

Хотя для одного запроса требуется довольно много строк.

Переформатирование синтаксиса SQL

Эта опция намного чище - она ​​будет читать код SQL и переформатировать его на основе языков ввода и вывода. Однако я вижу, что это гораздо более медленное решение, насколько это возможно.

Answer 1

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

Answer 2

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

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

Answer 3

Я бы порекомендовал строить SQL на основе классов и рекомендовать Doctrine , Zend_Db или MDB2 . И да, если для написания простых выборок требуется больше строк, но вы, по крайней мере, можете положиться на парсер и не нужно заново изобретать колесо.

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

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

Answer 4

Решением может быть использование разных наборов запросов для разных платформ с идентификаторами типа

MySql: GET_USERS = "SELECT * FROM users"

MsSql: GET_USERS = ...

PgSql: GET_USERS = ...

Затем при запуске вы загружаете необходимый набор запросов и ссылаетесь на

Db :: loadQueries (платформа):

$ users = $ db-> query (GET_USERS)