И насчет сиротского PDO. Если вы не пишите рамку на публику - на кой черт PDO? И даже если пишите, то маргиналами можно пренебречь. По наблюдениям их крайне мало.

$pdo_statement->fetchAll(PDO::FETCH_COLUMN);

Свистните, когда закончите, пжлст. Я начну писать класс-обертку на этот класс бд, который обертка над PDO или че там ещё, которая.... вобщем в доме, который построил Джек.

Это сейчс так модно, писать универсальные говноклассы.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

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

_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker

Игорь_Vasinsky
Есть более другие способы применения сил. Ну а так давай будем аппач переписывать, дабы понять, как он устроен.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

вы реально пишете на голом SQL в крупных проектах?

А почему на нем не писать? Чем он хуже HTML или PHP? Хотя есть люди, кто создает абстракции и над ними... Вот уж точно дом, который построил Джек. На хабре как-то раз статья была про абстракции с большим юмором. Когда человеку нужен был простой молоток, а закончилось все приобретением фабрики для фабрики по изготовлению молотков.

если будет нужно перепишут, написали же nginx, хотя это может быть немного другое

И получилась полная лажа. Единственный плюс в том, что он поддерживает формат htaccess от апача. Но это плагиат а не ноу-хау. Все дикие манипуляции онлайн, такие как наложение ватермарков на картинку при отображении или ресайз (!)... В каком вообще бреду это может понадобиться!? Во всем остальном нгинкс проигрывает с существенным отставанием своему иностранному конкуренту lighttpd.

Как-то раз я спросил у одного программиста, а чем нгинкс лучше? Ответ был (внимание): "Потому, что его пишет зачетный чувак! И вообще это круто..."

P.s. Я не случайно упомянул про goDB. Дело в том, что обертка не накладывает никаких абстракций над SQL. Просто немного расширяет функционал и делает его более удобным. Пример запроса:

$db->query('SELECT * FROM example WHERE id=?i', array($_POST['id']), 'assoc');

Здесь у нас что? Ожидается id типа int. Библиотека сама приводит $_POST['id'] к типу, только потом генерирует запрос. Или есть замечательный ключик ?s - это когда у нас ассоциативный массив "поле таблицы" => "значение". Много там различных "помогалочек", кому интересно, почитайте мануал. Все строковые плейсхолдеры ескейпятся соответствующей функцией. То есть ничего особенного совершенно, но пользоваться ИМХО крайне удобно. Создавать запросы одно удовольствие.

paul85 nginx хорошо отдает статику. на реальных проектах, где большое количество CRUD операций, без ORM и обобщающих абстракций над sql не обойтись.

paul85
есть пара пунктов которые мне в таком подходе не нравятся:
1. есть определенного рода соглашения, что нужно писать '?i' , '?s', и наверно еще всякое. В целом это не сложно запомнить, но я лентяй и люблю ctrl+space. в моем же классе нет никаких соглашений, есть только методы и их аргументы.
2. в запросе дополнительно производится поиск/замена плейсхолдеров
3. кэшировать такие запросы получится только целиком, либо придется парсить запрос чтоб понять чего он делает и чтоб правильно закешировать строки. пример к этому пункту:
есть страничка на которой выводится список всех деревьев на которых растут фрукты.
есть страничка поиска по фруктам + у каждого фрукта должна быть выведена инфа о дереве, на котором он растет.
так вот с моим классом все деревья с первой страницы попадут в кэш построчно. прописывание запроса через мой класс как бы сразу выделяет составные части SQL, и дополнительно парсить его не нужно. и на странице поиска фруктов будет только ОДИН запрос на поиск фруктов, а связанные с ними деревья уже вытащатся из кэша.

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

Эх, Николай. Взрослый дядька, а не хочешь принимать нового... Или вместо "а" нужно поставить "и".