- 1
- 2
- 3
$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");
Анонимус 27.12.2010 23:37 # −1
кстатиm о PDO Вы видимо так же не знали. ))
1_and_0 28.12.2010 01:54 # 0
Минусую, ИМХО, не ГК
striker 28.12.2010 02:54 # +1
Анонимус 28.12.2010 02:59 # +5
но Вы правы: это синонимы
telnet 28.12.2010 07:58 # +1
Анонимус 28.12.2010 12:39 # 0
Vasiliy 28.12.2010 12:49 # 0
Анонимус 28.12.2010 12:58 # 0
а еще потому что с глобальной переменной
interested 28.12.2010 15:15 # −1
Чем оно лучше собственной микро-архитектуры порождения из двух-трёх классов?
Vasiliy 28.12.2010 15:28 # +1
Lure Of Chaos 28.12.2010 15:32 # +3
Анонимус 28.12.2010 15:38 # 0
и вместо стандартной либы у нас будет 42 наколенных и кривых
и таких же жирных
удивительно, что такие очевидные всему остальному миру вещи -- Не очевидны некоторым пхпистам
Lure Of Chaos 28.12.2010 15:55 # 0
Лисапеды одобряю в 2 случаях:
1. стандартная либа слишком универсальна и тяжела для мелкого проекта
2. стандартная либа спроектирована на коленке(криво) и не рефакторится из соображений обратной совместимости
interested 28.12.2010 16:02 # 0
И да. 42 велосипеда лучше чем один стандартный и совершенный. Пролиферация, однако.
Стандартизация нужна лишь для общения в коммуникативной группе. Если группа разработчиков А не общается с группой B, то им и не нужна общая стандартизация.
wmmorgun 28.12.2010 19:02 # 0
Та библиотека что используется в сабже, безумно древняя, и давно не поддерживается, плюс ко всему не поддерживает новый алгоритм аутентификации, транзакции и прочую утварь.
guest 28.12.2010 19:10 # 0
Lure Of Chaos 28.12.2010 19:45 # −1
interested 28.12.2010 20:01 # −1
interested 28.12.2010 20:01 # 0
Коннектор устарел. Признаю, что PDO действительно действенно. Скомпилировано расширение полностью в обход стандартного коннектора.
Конечно, в таком случае, уже велосипеды лишние.
Анонимус 28.12.2010 22:05 # 0
2) Если Ваш программист существует в замкнутом мире и обладает неограниченым временем, то конечно лучше писать все с ноля.
Однако если Вы хотите что бы кроме автора кода еще кто-то мог с ним работать (как это принято в XP например) или что бы код можно было передать другому программисту или что бы в комманду можно было ввести разработчиков, словом сделать все то, что обычно делают в проектах сложнее гостевой книги из 50ти строк -- то стандартизация Вам только наруку. Нужно объяснять почему?
interested 28.12.2010 22:41 # 0
Конечно, я не буду переписывать nl2br, потому что она в точности реализует то, что мне нужно, да ещё и такой простой и мелкой единицей. А вот "умный" указатель, скорее всего, напишу свой, под свои цели.
Я полагаю, что стандартизации следует избегать по максимуму. И только в случаях исключительной необходимости, когда действительно возникает серьёзная потребность объединить коммуникации, стандартизация нужна.
На мой взгляд, COM -- вот истинный пример ужаса стандартизации... Решили сделать общение между компонентами, да поуниверсальнее, да вот чтобы прям всё "стандартным" образом. Получили ужасный неповоротливый дом. Работать с ним непросто, хотя и абстрактная идея очень хорошая и ясная.
На самом деле всегда существует целый спектр библиотек, которые выполняют одни и те же задачи, но как-то по-разному. Хотя можно было стандартизировать одну. Но зато есть выбор. Выбор -- это хорошо.
Ice 29.12.2010 02:07 # 0
Неа =)
Анонимус 29.12.2010 11:44 # 0
bugmenot 29.12.2010 11:47 # 0
это про голландских власовцев
Анонимус 29.12.2010 11:52 # +2
bugmenot 29.12.2010 13:03 # 0
guest6 30.12.2023 01:06 # 0
штурвалов
Анонимус 28.12.2010 15:37 # 0
2) простотой перехода на другую БД (при условии выноса запросов в отдельные файлы / хранимые процедуры)
3) единообразностью подхода, позволяющей программисту изучить "работу с БД в PHP". Как тут писал недавно товарищ: лучше понять концепцию, чем заучивать тонну несвязанных фактов.
interested 28.12.2010 15:51 # 0
Как же это связано с PDO? Конкретно.
Я так же легко смогу напрямую данные откуда-неизвестно пихануть в метод из PDO и просрать базу.
>простотой перехода на другую БД (при условии выноса запросов в отдельные файлы
Так простенькая таксономия собственного производства это решает быстрее и яснее для данной команды разработчиков.
>единообразностью подхода, позволяющей программисту изучить "работу с БД в PHP"
Странно звучит...
То есть, базы данных это какие-то "особые" программы, которые "должны" как-то "реализовываться" в "языке"?
Может это проблемы миграции из C, где у меня был голый MySQL API. Но мне яснее понимать, что база данных -- это ровно такая же программа, как и другие, которой можно делегировать какой-то функционал (хранения данных, например) через API, а не мыслить что-то "особенное".
Я вот понимаю JDBC -- там адаптеры предоставляются производителями баз данных, там ISO. Классы специфики отделены.
А в PDO ничего этого нет...
Анонимус 28.12.2010 22:01 # 0
2) зачем нужно собственное производство? и чем оно быстрее? Свое производство -- лишняя трата времени на создание того, что уже есть.
3) какое отношение ISO имеет к JDBC?
И разницы между PDO и JDBC нет никакой кроме того, что в мире Java понимают, зачем нужно JDBC, а в мире PHP любят велосипеды с квадратными колесами.
interested 28.12.2010 23:23 # 0
Совершенно не ясно.
Оттого, что вы связали переменную с частью запроса, вы не освободились от необходимости ставить "плотины" на эту переменную. Иначе вы точно также пропустите бяку.
>какое отношение ISO имеет к JDBC
Да, это я перегрелся. Привычка C++, чуть что -- кричать ISO.
Имеется в виду, что для JDBC существует стандарт того, как нужно осуществить адаптер. Это не ISO, конечно, а набор тестов, как я вычитал. Это позволяет производителям, например, баз данных заранее знать, что нужно сделать, чтобы подпихнуть адаптер под JDBC и быть уверенными, что разработчик сможет работать с их базой данных из под JDBC.
И много есть инструментов для того, чтобы дать возможность уже разработчиками адаптеров написать этот сопрягающий элемент, причём даже полностью на Java. А за счёт этого промежуточного уровня есть возможность даже корректировать запрос, то есть писать его в общем виде в смысле Java, а на выходе получить диалективное выражение.
Конечно, я про PDO знаю ещё меньше, чем про JDBC, надеюсь, что мне с PDO и работать-то не придётся. Но выглядит это PDO из описания, словно такой мощный синтаксический сахар.
Анонимус 29.12.2010 00:52 # 0
Вообще есть такой бест практис: немного почитать про то, о чем собираетесь спорить)
Наличие более внятного контракта для JDBC это лишь отражение того факта, что в Java вообще принято мыслить интерфейсами и концепциями, а не конкретными функциями как в php, и появление поддержки новой БД в Java, .NET или perl это всего лишь появление нового драйвера (имплементации), с уже знакомыми нам интерфейсами. В случае же классического пхп подхода -- это появление пачки новых функций в глобальной области видимости с какими-то префиксами и разнообразным синтаксисом (вплоть до разного порядка параметров)
BLDPAXP 25.08.2021 02:16 # 0