Добрый день.

При разрабатывание проектов с использованием СУБД часто встает вопрос об быстром развертывание проекта на новую СУБД или драйвер (например: миграция с mysql на mysqli, или замена mysql на sqlite) без изменения основного кода. В этом нам помогают обертки, причем они довольно громоздкие:


Что очень не удобно - тонны строк. В итоге мне это надоело использовать и решил искать альтернативу, и вроде нашел её


Что скажите?

Добавлено @ 12:50
P.S. данное решение не означает что его нужно использовать сломя голову. Тем более тесты не проведены и не понятно стоит ли такое использовать. Все чисто теоретически пока что   

Это сообщение отредактировал(а) MoLeX - 7.6.2011, 13:04

Я так и не могу понять боязни еще пары сотен строк в проекте. А ведь все что вы получаете это экономия LOC.

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

Да, этого в данном способе нету. Только если расширять/добавлять новый метод query()

Добавлено через 47 секунд

это не боязнь, это безделье которое рождает подобные вещи)

я делал както проект полностью на mysqli но потом бац на хостинге нету mysql чтоже делать что же делать написал обертку простого mysql схожего на mysqli и не переписывал сотни кода ). 

А некоторые вообще ORM используют )  
// а то чет холивара то и не получается... 

есть такое)

не ORM меня не когда не вдохновляло а вот обертка самое то причем я на столько люблю mysqli что везде его использую )

И что, потом, при обновлении данных рыскать по коду и переписывать все запросы?

А чем PDO не устроил?

ну, например, округлением float до не помню какого знака после запятой при бинде параметров. 

Ну да надо же себя чем то занять   

а если перегрузить метод из PDO?

Нет холивара? Пожалуйста:

Вы что так часто меняете СУБД? Каждый день переезжаете с сервера на сервер?
1) Если у Вас свой сервер, то поставить нужную СУБД не будет ни каких проблем.
2) Если у Вас хостинг и он не предоставляет популярные SQLite или MySQL, то этот хостинг попросту не нужен.

Я просто замечаю, что кое-кому делать нефиг, начинает писать много лишнего в проект. Раз пишите под несколько СУБД, сразу на разных языках пишите, вдруг на хостинге нет PHP, но есть Python или Ruby

  

часто работаю с заказами, в которых заказчики сразу говорят - "мне mysql, mysqli, sqlite, etc". А ядро используется одно и то же.

Добавлено через 1 минуту и 1 секунду

Надо SamDark'у сказать, пусть Yii переводят на эти языки

Всё равно не понимаю, зачем в одном проекте сразу всё? В разных проектах, может и нужно.
Не разу не пришлось использовать что-то отличное от MySQL. А если нравится объектный подход, то лучше использовать тогда объектно-реляционную организацию данных. Читаем: http://forum.wen.ru/?p=3&f=6&t=396249 может найдете для себя что-то   

 СкажЕте.
Скажу, что полностью бессмысленно: получим в итоге то же самое, только уродливое.  При этом с полным отсутствием ООП, а его умеют даже стандартные классы.

Эти обертки вводятся для удобства и для унификации. Тут же нет ни того, ни другого, более того все даже гораздо хуже банального класса mysqli в плане удобства и проектирования(объект даже в примере выше линк внутри себя не сохранил).

Чтобы исправить:
1) Хранить в себе служебные данные, пользователю они как пятая нога на зеркале.
2) Унифицировать методы(чтобы работа с мускулом не отличалась от sqlite).
3) Добавить методы типа fetchAll, fetchRow, fetchOne, fetchPairs, fetchCol, insert, update, delete.
4) После написания всего этого спросить себя: "Нахрена я это писал и тратил время, если мог просто взять качественную готовую обложку. Наверное мне надо лечиться от мании величия и не считать чужой качественный оттестированный тысячами разработчиков документированный проверенный временем код заведомо хуже своего, написанного за день на коленке.". После чего стереть проект и воспользоваться аналогичным(но более качественным) решением.

Использование единого ядра к разным хранением данных (и не только) называется портируемостью системы, одно из мощных свойств ООП в целом. Данные при этом могут браться из нескольких  распределённых серверов БД с разными СУБД, или вообще файловых серверов данных.
ORM не всегда лучше в использовании, так как от проекта к проекту (в плане от автора к автору) имеет специфический функционал, к которому:

Надо дополнительно изучать специфику работы с моделью особенно при составлении сложных и взаимосвязанных запросах,где каждый по разному эту специфику реализовывает
Имеет целесообразность только в определённом кругу разработчиков, а так же в продолжительном проекте (например фреймворке)
И так сказать "религия" разработчика, то есть ну не к чему многим усложнения в виде ORM которая накладывает дополнительные проблемы реализации, по сравнению скажем с PDO или приблизительно с такой же обёрткой.

Это сообщение отредактировал(а) Sentox - 11.6.2011, 09:10

5) Меня попросили продать продукт, содержащий лицензионное PDO  и тогда, на хрена я выкинул свою обёртку ...   

1 не потребует деньги если ты пишешь коммерческий продукт
2 это ведь так интересно написать что то лишние и бесполезное =)