Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
$result = mysql_query ("SELECT f.name, f.category, c.name AS cat_name, f.size, f.datetime, f.filename " .
"FROM ${DB_PREFIX}_files AS f, ${DB_PREFIX}_categories AS c " .
"WHERE f.id=$id AND f.category = c.id");На момент написания совершенно не подозревал о существовании JOIN'а.
Запостил: 
byss,
(Updated )
кстатиm о PDO Вы видимо так же не знали. ))
Минусую, ИМХО, не ГК
но Вы правы: это синонимы
а еще потому что с глобальной переменной
Чем оно лучше собственной микро-архитектуры порождения из двух-трёх классов?
и вместо стандартной либы у нас будет 42 наколенных и кривых
и таких же жирных
удивительно, что такие очевидные всему остальному миру вещи -- Не очевидны некоторым пхпистам
Лисапеды одобряю в 2 случаях:
1. стандартная либа слишком универсальна и тяжела для мелкого проекта
2. стандартная либа спроектирована на коленке(криво) и не рефакторится из соображений обратной совместимости
И да. 42 велосипеда лучше чем один стандартный и совершенный. Пролиферация, однако.
Стандартизация нужна лишь для общения в коммуникативной группе. Если группа разработчиков А не общается с группой B, то им и не нужна общая стандартизация.
Та библиотека что используется в сабже, безумно древняя, и давно не поддерживается, плюс ко всему не поддерживает новый алгоритм аутентификации, транзакции и прочую утварь.
Коннектор устарел. Признаю, что PDO действительно действенно. Скомпилировано расширение полностью в обход стандартного коннектора.
Конечно, в таком случае, уже велосипеды лишние.
2) Если Ваш программист существует в замкнутом мире и обладает неограниченым временем, то конечно лучше писать все с ноля.
Однако если Вы хотите что бы кроме автора кода еще кто-то мог с ним работать (как это принято в XP например) или что бы код можно было передать другому программисту или что бы в комманду можно было ввести разработчиков, словом сделать все то, что обычно делают в проектах сложнее гостевой книги из 50ти строк -- то стандартизация Вам только наруку. Нужно объяснять почему?
Конечно, я не буду переписывать nl2br, потому что она в точности реализует то, что мне нужно, да ещё и такой простой и мелкой единицей. А вот "умный" указатель, скорее всего, напишу свой, под свои цели.
Я полагаю, что стандартизации следует избегать по максимуму. И только в случаях исключительной необходимости, когда действительно возникает серьёзная потребность объединить коммуникации, стандартизация нужна.
На мой взгляд, COM -- вот истинный пример ужаса стандартизации... Решили сделать общение между компонентами, да поуниверсальнее, да вот чтобы прям всё "стандартным" образом. Получили ужасный неповоротливый дом. Работать с ним непросто, хотя и абстрактная идея очень хорошая и ясная.
На самом деле всегда существует целый спектр библиотек, которые выполняют одни и те же задачи, но как-то по-разному. Хотя можно было стандартизировать одну. Но зато есть выбор. Выбор -- это хорошо.
Неа =)
это про голландских власовцев
штурвалов
2) простотой перехода на другую БД (при условии выноса запросов в отдельные файлы / хранимые процедуры)
3) единообразностью подхода, позволяющей программисту изучить "работу с БД в PHP". Как тут писал недавно товарищ: лучше понять концепцию, чем заучивать тонну несвязанных фактов.
Как же это связано с PDO? Конкретно.
Я так же легко смогу напрямую данные откуда-неизвестно пихануть в метод из PDO и просрать базу.
>простотой перехода на другую БД (при условии выноса запросов в отдельные файлы
Так простенькая таксономия собственного производства это решает быстрее и яснее для данной команды разработчиков.
>единообразностью подхода, позволяющей программисту изучить "работу с БД в PHP"
Странно звучит...
То есть, базы данных это какие-то "особые" программы, которые "должны" как-то "реализовываться" в "языке"?
Может это проблемы миграции из C, где у меня был голый MySQL API. Но мне яснее понимать, что база данных -- это ровно такая же программа, как и другие, которой можно делегировать какой-то функционал (хранения данных, например) через API, а не мыслить что-то "особенное".
Я вот понимаю JDBC -- там адаптеры предоставляются производителями баз данных, там ISO. Классы специфики отделены.
А в PDO ничего этого нет...
2) зачем нужно собственное производство? и чем оно быстрее? Свое производство -- лишняя трата времени на создание того, что уже есть.
3) какое отношение ISO имеет к JDBC?
И разницы между PDO и JDBC нет никакой кроме того, что в мире Java понимают, зачем нужно JDBC, а в мире PHP любят велосипеды с квадратными колесами.
Совершенно не ясно.
Оттого, что вы связали переменную с частью запроса, вы не освободились от необходимости ставить "плотины" на эту переменную. Иначе вы точно также пропустите бяку.
>какое отношение ISO имеет к JDBC
Да, это я перегрелся. Привычка C++, чуть что -- кричать ISO.
Имеется в виду, что для JDBC существует стандарт того, как нужно осуществить адаптер. Это не ISO, конечно, а набор тестов, как я вычитал. Это позволяет производителям, например, баз данных заранее знать, что нужно сделать, чтобы подпихнуть адаптер под JDBC и быть уверенными, что разработчик сможет работать с их базой данных из под JDBC.
И много есть инструментов для того, чтобы дать возможность уже разработчиками адаптеров написать этот сопрягающий элемент, причём даже полностью на Java. А за счёт этого промежуточного уровня есть возможность даже корректировать запрос, то есть писать его в общем виде в смысле Java, а на выходе получить диалективное выражение.
Конечно, я про PDO знаю ещё меньше, чем про JDBC, надеюсь, что мне с PDO и работать-то не придётся. Но выглядит это PDO из описания, словно такой мощный синтаксический сахар.
Вообще есть такой бест практис: немного почитать про то, о чем собираетесь спорить)
Наличие более внятного контракта для JDBC это лишь отражение того факта, что в Java вообще принято мыслить интерфейсами и концепциями, а не конкретными функциями как в php, и появление поддержки новой БД в Java, .NET или perl это всего лишь появление нового драйвера (имплементации), с уже знакомыми нам интерфейсами. В случае же классического пхп подхода -- это появление пачки новых функций в глобальной области видимости с какими-то префиксами и разнообразным синтаксисом (вплоть до разного порядка параметров)