Чи має сенс писати свою обгортку над PDO
PDO з коробки малозабільний і незручний: не вважає час і статистику запитів, не підтримує лінивого з'єднання, пулу з'єднань, транзакцій, нормальних плейсхолдерів. тому обгортку писати варто у 90% випадків.
А ось написати обгортку, що дозволяє прозоро для коду змінювати СУБД, вам не вдасться. MySQL має LIMIT, INSERT ON DUPLIATE KEY UPDATE і купу речей, яких немає в інших БД. Що ви з ними робитимете, щоб змусити працювати в ораклі?
> При такому варіанті перемикань між типами БД, у Вас будуть складнощі з оптимізацією витяжки/зміни даних.
Пояснить за якого варіанта? Якщо обгортка грамотно написана, перемикати БД зовсім не складно, а навіть зручно.
Не зовсім зрозуміле завдання, PDO без будь-яких обгорток із коробки є DBAL. А ось обгортки вчитися писати варто, особливо з ітераціями щодо збільшення функціональності, щоб заздалегідь продумували точки входу та розширення. У мене така обгортка обов'язкова під час навчання джуніорів, профіт величезний.
Щодо PDO та підтримки різних баз даних, то ця ідея з коробки не працює, т.к. можна писати кастомний SQL, який може підтримуватися усіма БД, тому потрібен як мінімум Query Builder.
на цьому рівні це виключно шкільне завдання і практичної цінності у неї немає - варто тільки копнути трохи глибше простого селекту і з'ясовується, що движки сильно відрізняються і банальне id останньої вставки може викликати головний біль при портуванні.
абстрагуватися треба вище - на рівні об'єктів та операцій роботи з ними. власне оптимізація виробляється вже під движок і може викликати зміни лише на рівні порядку, виду запитів чи окремих операцій. Тут обійтися обгорткою над викликами до бази не обійтись.
А взагалі завдання доступу до різних двигунів досить характерні для інтеграції (зростити документи в різних системах обороту, сполучити VCS, трекер, тест менеджер і системи бізнес процесів), для різного роду поділу за рівнями (sq-nosql, зовнішня та локальна, серверна та клієнтська) )