Вот давно хотел узнать. Зачем пишут свои функции, если есть стандартные. Особенно касается БД?
Например надо вывести из базы данные, можно же ведб просто везде писать


Зачем делают вот так???


Ведь это требует больше ресурсов, мало того вызывается своя функция, так ещё и стандартная. Зачем это вообще нужно?

Для повышения уровня абстракции... 
Читать скрипты, использующие стандартные функции для работы с БД напрямую - очень грустное занятие, ибо куча кода, который повторяется из раза в раз, забивая на DRY-принцип... К тому же если тебе приспичит поменять СУБД, то достаточно будет переписать единственный класс для работы с БД, а не все скрипты...

В наше время нервы программистов уже ценятся гораздо выше, чем вычислительные ресурсы, да и не так уж много ресурсов нужно на вызов функции переходника, как тебе кажется...
А если будешь продолжать делать по-своему, то потом будешь делать так:   

это неправда. различные СУБД различаются не функциями API, а диалектами языка. поэтому смной класса дело не ограничится.
В общем - не довод.


Это неправда. Скрипты читаются прекрасно, на автомате. Это примерно как английский язык - худо-бедно все его понимают, слова "йес" и "ноу" знают все, и понимают без перевода. С собственными функциями приходится переводить. 
В общем, на чтение сильного влияния не оказывают.

Добавлено через 12 минут и 35 секунд
supercelt, я тебе объясню волшебное правило, с помощью которого легко определять, нуже функция, или нет.
В функцию следует заключать часто используемый фрагмент кода.

Рассмотрим твой вопрос с этой точки зрения.
Для работы с бд переопреденяют не одну функцию, а несколько.
к примеру, чтобы получить одну строку из БД, надо в самом минимальном случае выполнить две функции - mysql_query и mysql_fetch_array. Если же делать по-человечески, то надо
а) присвоить переменной значение запроса а не писать его прямиком в функции
б) выполнить запрос
в) проверить - успешно ли
г) если неуспешно, то обработать ошибку, используя переменную из пункта "а" и mysql_error()
д) получить массив.

Уже 5 пунктов. вполне достойно помещения в функцию, согласись?

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

что значительно сократит объем кода.

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

Правда, правда, тут зависит от уровня создаваемой абстракции... Про Active Record слыхал? Вижу что нет, так что почитай, повысь свой уровень, вместо бессмысленных заявлений типа "всё неправда, один я такой умный, что могу всю неправду своими словами рассказать так, что будет правда"...   

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

Это сообщение отредактировал(а) source777 - 17.2.2008, 16:03

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

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

source777, чтобы можно было легко и безболезненно сменить движок бд, уровень абстракции библиотеки соответственно должен быть таким, чтобы пользователь НЕ имел дело с запросами. В библиотеках, где запросы все-таки приходится вводить, разумеется и эти запросы так же придется править.

Это сообщение отредактировал(а) flashaa - 17.2.2008, 20:54

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