SELECT
tb.*, tb2.name, tb2.body_m, tb3.catalog_id, tb4.status_id
FROM
product tb
LEFT JOIN ru_product tb2 ON tb2.product_id=tb.id
LEFT JOIN product_catalog tb3 ON tb3.product_id=tb.id
LEFT JOIN product_status_set tb4 ON tb4.product_id=tb.id
WHERE
tb.active='1' AND tb3.catalog_id=? AND tb3.product_id!='10'
GROUP BY tb.id
ORDER BY rand()
LIMIT 6
нормально смотрится, если бардак в коде не разводить. К тому же это на много нагляднее.
А с несколькими строчками сложнее — либо оно маленькое, шустрое, но не сильно функциональное, либо вырастает в монструозное чудовище. Вы написали гораздо больше чем несколько строчек кода, а ведь это всего лишь обертка для PDO и она ооочень многого не умеет (OUTER JOIN, подзапросы, вызов хранимых процедур и т.д.).
2. Если используете PDO::prepare, то да, дополнительно эскейпить не нужно. Но я бы сравнил по быстродействию.
3. Чудо-пользователи могут создать табличку с полем where и привет. Никто же не мешает же делать что-то вроде t1.`field1`, где t1 — алиас для таблицы `table1`.
PS Лично мне идея написать обертку для PDO не кажется очень хорошей.
угумс, я одну такую железяку нашел, но вопросы совместимости, нужно было брать и пробовать, а тем, кто на этом железе работает, было не до того. Да и финансирование выбить там не просто.
Еще что-то там более чем нужно — агрегат ощутимо пользует проц, железка жутко медленная. Но это был немецкий университет, эксперименты там не уместны. Как только станет «сильно надо» — будет куплена полностью новая железка.
Увы, даже не консерватор а ретроград.
Дело не в интерфейсе — на офисных компах (для офисных задач) XP подходит более чем, не вижу смысла (может плохо смотрю?) ставить что-то более тяжелое. А на своем буке — ну нравится оно мне, могу же я позволить себе такую блажЪ ))
1. имхо лучше называть методы аналогично соответствующим SQL функциям — проще, нагляднее.
2. очень полезно было бы вставить mysql_real_escape_string или свой ее аналог для отсечения всяких нехорошестей. И, при беглом просмотре кода, не нашел (плохо искал?) где добавляются кавычки вокруг значений. Что если значение поля будет (без окружающих кавычек) «мама мыла 'раму', но это ей не нравилось»?
3. было бы не лишним добавить "`" для названий полей
4. может быть полезным сделать обертки для getRecords, которые будут возвращать строку как массив, вложенный массив для списка объектов, одно значение, пару значений и т.д.?
SELECT `key`=>`value` FROM `table` => array(key=>value)
SELECT `value` FROM `table` LIMIT 1 => value
SELECT `value` FROM `table` => array(value, value, value)
SELECT * FROM `table` LIMIT 1 => array(...)
SELECT * FROM `table`=> array(array(...), array(...), ...)
Это заметно упрощает работу с библиотекой
PS Лично я (специфика работы) предпочитаю insert/update/delete делать через аналогичную библиотеку, а вот select`ы писать руками — реализация всеобъемлющей функции будет слишком тяжелой: вложенные запросы, сложные условия выборки, вызов хранимых процедур и далее по списку.
Согласен, есть сонм багов из разряда «если вот так и вот так, а потом вот тут и потом вот так, то тогда в лунную ночь перед рождеством случится то-то». Но:
а) в вышеприведенном списке есть и весьма частые баги
б) уход производителя в премиум-сегмент, зачастую, не спасает от багов ни на 99% ни на 80%, apple тому пример.
Я о том и написал — не надо лить 76 бензин в biturbo.
Но за свой не дешевый 95-й (1.78 евро/литр, однако) я хочу чтобы машина ехала так как написано в спецификации.
Позволю себе не согласиться. Это вопрос ответственности.
Потратить <5% ресурсов разработки на правку хотя бы самых очевидных багов — не шибко дорого. Но большинство компаний просто не хотят этого делать, следуя принципу «юзер хавает». Нет ответственности — не мы такие, мир таков. Если бы, грубо говоря, пользователи имели возможность плюнуть в кофе тимлиду разработчиков/топменеджеру когда что-то падает — отношение было бы другим.
Опять же, high-end сегмент в последнее время очень сильно приблизился к ширпотребу по качеству. Китайская трубка на андроиде может работать более внятно чем очередной айфон, а дохленький фордовский мотор может отбегать (при равном уходе) больше пальцастого баварского.
Нет, подождите. Новый юзер покупает ифон 4s, платит ощутимые деньги и хочет получить за них хороший софт.
иос5 на ифон3, увы, не разрешено производителем/железом. Я бы с удовольствием заливал в свою машину 76 бензин, но увы и ах. Я не покупаю присадки и не пляшу с бубном чтобы машина на нем ездила — это прикольно ради фана, но не более того. Чтобы просто ездить я заливаю 95-й, который рекомендован производителем.
По поводу машин согласен, но там математика чуть другая. Году эдак в 2000-м производители смекнули что не надо делать машины с ресурсом 15+лет, это не выгодно. В России этого мало, а в Европе куча людей покупают новую машину (зачастую весьма недешевую) и ездят на ней 10 лет. Сейчас это уже не прокатывает и машину приходится менять лет через 5.
нормально смотрится, если бардак в коде не разводить. К тому же это на много нагляднее.
А с несколькими строчками сложнее — либо оно маленькое, шустрое, но не сильно функциональное, либо вырастает в монструозное чудовище. Вы написали гораздо больше чем несколько строчек кода, а ведь это всего лишь обертка для PDO и она ооочень многого не умеет (OUTER JOIN, подзапросы, вызов хранимых процедур и т.д.).
3. Чудо-пользователи могут создать табличку с полем where и привет. Никто же не мешает же делать что-то вроде t1.`field1`, где t1 — алиас для таблицы `table1`.
PS Лично мне идея написать обертку для PDO не кажется очень хорошей.
Дело не в интерфейсе — на офисных компах (для офисных задач) XP подходит более чем, не вижу смысла (может плохо смотрю?) ставить что-то более тяжелое. А на своем буке — ну нравится оно мне, могу же я позволить себе такую блажЪ ))
2. очень полезно было бы вставить mysql_real_escape_string или свой ее аналог для отсечения всяких нехорошестей. И, при беглом просмотре кода, не нашел (плохо искал?) где добавляются кавычки вокруг значений. Что если значение поля будет (без окружающих кавычек) «мама мыла 'раму', но это ей не нравилось»?
3. было бы не лишним добавить "`" для названий полей
4. может быть полезным сделать обертки для getRecords, которые будут возвращать строку как массив, вложенный массив для списка объектов, одно значение, пару значений и т.д.?
SELECT `key`=>`value` FROM `table` => array(key=>value)
SELECT `value` FROM `table` LIMIT 1 => value
SELECT `value` FROM `table` => array(value, value, value)
SELECT * FROM `table` LIMIT 1 => array(...)
SELECT * FROM `table`=> array(array(...), array(...), ...)
Это заметно упрощает работу с библиотекой
PS Лично я (специфика работы) предпочитаю insert/update/delete делать через аналогичную библиотеку, а вот select`ы писать руками — реализация всеобъемлющей функции будет слишком тяжелой: вложенные запросы, сложные условия выборки, вызов хранимых процедур и далее по списку.
а) в вышеприведенном списке есть и весьма частые баги
б) уход производителя в премиум-сегмент, зачастую, не спасает от багов ни на 99% ни на 80%, apple тому пример.
Но за свой не дешевый 95-й (1.78 евро/литр, однако) я хочу чтобы машина ехала так как написано в спецификации.
Потратить <5% ресурсов разработки на правку хотя бы самых очевидных багов — не шибко дорого. Но большинство компаний просто не хотят этого делать, следуя принципу «юзер хавает». Нет ответственности — не мы такие, мир таков. Если бы, грубо говоря, пользователи имели возможность плюнуть в кофе тимлиду разработчиков/топменеджеру когда что-то падает — отношение было бы другим.
Опять же, high-end сегмент в последнее время очень сильно приблизился к ширпотребу по качеству. Китайская трубка на андроиде может работать более внятно чем очередной айфон, а дохленький фордовский мотор может отбегать (при равном уходе) больше пальцастого баварского.
иос5 на ифон3, увы, не разрешено производителем/железом. Я бы с удовольствием заливал в свою машину 76 бензин, но увы и ах. Я не покупаю присадки и не пляшу с бубном чтобы машина на нем ездила — это прикольно ради фана, но не более того. Чтобы просто ездить я заливаю 95-й, который рекомендован производителем.
лажа = лажа
что хотят сказать то и пишут