Comments 15
Это же полный звиздец…
Сколько можно уже говорить про глобальные переменные, про die, про phpDoc и т.д. и т.п. и вообще про ООП?
Сколько можно уже говорить про глобальные переменные, про die, про phpDoc и т.д. и т.п. и вообще про ООП?
А если человеку проект достался в поддержку?
Мне без разницы, в каком стандарте комментарии к коду.
die? Читается просто. Или автор должен был каким-то ООП способом вывести строчки на экран и потушить свой супер-мега фреймворк, да еще и без die|exit?
Мне без разницы, в каком стандарте комментарии к коду.
die? Читается просто. Или автор должен был каким-то ООП способом вывести строчки на экран и потушить свой супер-мега фреймворк, да еще и без die|exit?
> А если человеку проект достался в поддержку?
При чём тут это? Мы говорим об этой статье и коде, который писался для этой статьи? Или нет?
> Мне без разницы, в каком стандарте комментарии к коду.
Откройте для себя радость автодополнения кода и «сёрфинга» по коду в IDE. Правильные комментарии в этом очень сильно помогают.
> die? Читается просто.
Запись в лог? Вывод ошибки в шаблоне? throw new exception(«Не могу соединится с Основной базой данных»); читается ни чуть не хуже. Сразу же может появиться вопрос: но это же обучающая статья, почему бы просто die не сделать? Отвечаю: один из способов обучения — это подражание, поэтому в обучающих статьях нужно стремиться к правильной реализации.
При чём тут это? Мы говорим об этой статье и коде, который писался для этой статьи? Или нет?
> Мне без разницы, в каком стандарте комментарии к коду.
Откройте для себя радость автодополнения кода и «сёрфинга» по коду в IDE. Правильные комментарии в этом очень сильно помогают.
> die? Читается просто.
Запись в лог? Вывод ошибки в шаблоне? throw new exception(«Не могу соединится с Основной базой данных»); читается ни чуть не хуже. Сразу же может появиться вопрос: но это же обучающая статья, почему бы просто die не сделать? Отвечаю: один из способов обучения — это подражание, поэтому в обучающих статьях нужно стремиться к правильной реализации.
Простите конечно, но даже если назвать написанный код «псевдокодом», он ужасен. Как со стороны php (мне хватило глобальных переменных) так и со стороны бд с alter table на каждое изменение свойств (или типов изображений ).
Пример запроса к Основной базе, путем соединения нескольких таблиц в одну. Такой запрос априори будет работать медленней, чем простой запрос, без соединений.
Индексы никто не отменял, расставьте их правильно и разницу, уверен, вы не почувствуете.
Индексы никто не отменял, расставьте их правильно и разницу, уверен, вы не почувствуете.
Прочитав вступления, надеялся удивить оригинальное решение по организации данных для базы товаров, а в итоге прочитал статью ни о чем. Суть проблемы не раскрыта, решение на коленке, так работает 90% существующих скриптов только вот тут еще атрибуты как-то странно представлены. Отличная статья описывающая проблему реляционных баз при создании магазина kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ (одной картинкой).
Да уж… Код такой, что Фаулер с Беком нервно курят.
Покажите пожалуйста EXPLAIN ваших sql запросов на живых таблицах. Очень интересно.
И, кстати.
// Как сделать так, чтобы у товара А были одни свойства, а у товара Б — другие
Есть замечательный шаблон EAV. Он создан именно для этого и если его правильно приготовить станет настоящим подарком.
// Как сделать так, чтобы у товара А были одни свойства, а у товара Б — другие
Есть замечательный шаблон EAV. Он создан именно для этого и если его правильно приготовить станет настоящим подарком.
А что за шаблон? Не могли бы вы дать ссылку? Буду вам благодарен
Пожалуйста: bit.ly/wGoXhA
UFO just landed and posted this here
Sign up to leave a comment.
Мультимагазин. Статья для начинающих веб-программистов