По уму просто добавить поле для категории в котором будет хранится шаблон и брать его оттуда, а не вычислять в коде на основе ИД.
Как крайне облегченный вариант этой идеи
$_a=array(12=>'/template/product/XXX.tpl',13=>'/template/product/zzz.tpl'); //храним шаблоны для ид категорий в массиве, хотя и не в базе if(isset($_a[$this->data['layout_id']])) $this->template = $this->config->get('config_template').$_a[$this->data['layout_id']]; elseif (file_exists(DIR_TEMPLATE . $this->config->get('config_template') . '/template/product/category.tpl')) { $this->template = $this->config->get('config_template') . '/template/product/category.tpl'; } else $this->template = 'default/template/product/category.tpl';
if ($this->data['layout_id'] == 12) {$this->template = $this->config->get('config_template') . '/template/product/XXX.tpl'; } elseif (file_exists(DIR_TEMPLATE . $this->config->get('config_template') . '/template/product/category.tpl')) { $this->template = $this->config->get('config_template') . '/template/product/category.tpl'; } else { $this->template = 'default/template/product/category.tpl'; }
Логично продолжая Вашу идею
if ($this->data['layout_id'] == 12) {$this->template = $this->config->get('config_template') . '/template/product/XXX.tpl'; } elseif ($this->data['layout_id'] == 13) {$this->template = $this->config->get('config_template') . '/template/product/ZZZ.tpl'; } elseif (file_exists(DIR_TEMPLATE . $this->config->get('config_template') . '/template/product/category.tpl')) { $this->template = $this->config->get('config_template') . '/template/product/category.tpl'; } else { $this->template = 'default/template/product/category.tpl'; }
Вы правы для их ниши.
Но у ТС бюджет 35 тысяч, и не долларов.
Вы правы, отчасти, но все же это скорее юзабилити.
Но суть в другом - как Вы это формулировать в ТЗ собираетесь? "что бы вжух вжух и покупку сделал"? А оценивать как реализацию? Да никак:) В этом и проблема с дизайном, на него невозможно составить адекватное ТЗ, по которому можно было бы принимать работу и спрашивать.
Опять же, чекауты эти - это же не "вжух вжух и сделал потому что умный", а "нарисовал 20 вариантов, провел тестирование на целевой аудитории, нарисовал еще 20 вариаций лучшего, запустил на сайте разные варианты для оценки конверсии, выкинул лишние, подправил оставшуюся - выдал клиенту", т.е. опять же - никакого "изначального ТЗ по которому можно спрашивать".
Если нужен "очередной сайт", то не творческая, правда тогда непонятно почему не использовать шаблон изначально.
Но мы вообще о том, что ТЗ на дизайн (в отличии от верстки и программинга) допускает максимально возможное количество толкований.
"Использовать теплые цвета", фонт цвета "фуксии", "блоки должны гармонично совмещаться" и т.д., буквально каждый второй термин можно понимать десятком разных способов. Не говоря уже о таких абстракциях как "техностиль" и прочее.
И даже портфолио не поможет, т.к. никогда не знаешь сколько заплачено за этот сайт в портфолио, сколько там было замечаний, насколько там было подробное ТЗ и как сильно деградировал изменил стиль дизайнер с тех пор.
При этом детальная разработка ТЗ (где указываются ргб цвета и попиксельные позиции элементов) чуть более чем бессмысленна, т.к. по сути работу дизайнера и будешь выполнять.
По нашему опыту, если нет хотя бы 500 долларов просто на дизайн (при этом с отдельным бюджетом на оплату всех замечаний вида "вот этот молочный цвет недостаточно молочный"), то больше смысла поискать платный шаблон (или тыкнуть в сайт конкурента:) ), набросать к нему замечаний "что надо доработать" и вот это как ТЗ спускать на фриланс - будет качественнее.
Договор или не договор в дизайне значения не имеет, т.к. дизайнер всегда имеет скажет "я так вижу" (и самое подлое - так и будет искренне думать), поэтому если что-то не указано четко в ТЗ (хочешь молочный - укажи ргб код), то никаких "подразумеваний" там не будет, нарисует как сочтет нужным.
Хорошая верстка это вопрос религиозный, т.к. всегда можно найти мобильный девайс на котором она будет кривая, а под весь зоопарк ее не сделаешь. Но для лендинга можно уложить хорошую верстку в 200-300 баксов, хотя "мультяшные персонажи" настораживают, если там винни-пух должен был за пчелами летать, то это уже другое дело.
p.s.: Дизайн и сложную верстку всегда заказываем, так что цены не от балды.
Еще двое.
Знаем.
А еще знаем, что когда в руках молоток, то всё вокруг гвозди и очень хочется "специально для еще одних всех" поделиться инструкцией по использованию молотка... даже когда надо завернуть шуруп и у человека в руках уже отвертка:)
Объясним что мы в данном случае (во фразе про молоток и шурупы) имеем ввиду.
Сначала по поводу "шурупов".
ТС выбирает `browser`,`stream_id`,`source_id`,`service_id`,`user_id` , ему нужны представители строчки с уникальным browser и агрегатных функций он не использует.
Напомним, что груп-бай сделан для работы с группами - собирает группу из всех данных, а дистинкт для работы с уникальными значениями - берет данные первой попавшейся строчки.
distinct и group by часто дают одинаковый результат, но не всегда, поэтому когда работа с группами не нужна - нужен distinct, а не group by.
Теперь по поводу "молотка."
Дело в том, что distinct (в отличии от group by) сортировки по умолчанию не включает, поэтому order by null ему не нужен.
Обратите внимание что тот кусочек мануала что Вы привели - относится именно к group by, но никак не касается distinct, посмотрите мануал по distinct - убедитесь.
Лимиты в виде limit x,y тут не решат вопрос совсем.
Объясним. ТС очевидно нужные все данные.
В отсутствии сортировки по основному полю (browser) порядок выборки данных будет непредсказуем. А значит бить один большой запрос на лимиты нельзя - данные могут дублироваться или пропускаться.
В присутствии сортировки надо помнить о том как работает лимит и что для выполнения limit 10000,1000 мускул пролистает все 11000 записей, поэтому нет никакого смысла выбирать по тысяче предыдущие 10 тысяч, все они и так будут в последнем запросе.
join в данном случае так себе идея.
Лучше сначала выбрать browser_id, потом отдельным запросом browser по этим id.
Когда идет работа с большими данными, то даже при использовании innodb (а у автора может myisam) занимать две таблицы вместо одной на заметный срок нет смысла, по крайней мере в ситуации когда из второй таблицы просто подтягиваются данные по ключам.
А вообще еесли вопрос не решится заменой выносом user_agent в отдельную табличку со ссылкой на нее через browser_id, то с точки зрения производительности больше смысла будет в том, что бы сделать отдельную таблицу `browser`,`stream_id`,`source_id`,`service_id`,`user_id` сделать там browser уникальным и складывать в нее только значения с user_id<>0. Скорее всего она будет крошечная (юзеров обычно меньше анонимов), выборка как следствие будет реактивная (таблица меньше + дублирования строк с браузерами не будет), а накладные расходы на вставку в нее значений ничтожными (в меру ее размера хотя бы).---------- Добавлено 08.08.2017 в 02:14 ----------
ZemAN,
freelance.ru как и free-lance.ru (и некоторые другие) это рассадник посредников и менеджеров.
Это обусловлено в первую очередь их ценовой политикой, конечному исполнителю держать живой рабочий аккаунт там экономически невыгодно, вот тупо экономически невыгодно, от слова вообще.
Поэтому называемые там цены можно смело делить на 2-4 и тогда будет понятно, сколько получит конечный исполнитель который возьмется исполнять эту работу. А низкая цена как всегда гарантирует низкое качество.
По той же причине (посредники и менеджеры) реакция на замечания будет по принципу "испорченного телефона", пока 1-2-3 звена ее переврут и перешлют - смысл потеряется.
И по той же причине возможно топ-ракета не отдает дизайн, он не то что бы не хочет, у него его просто нет в принципе, он у конечного исполнителя, который его не отдает ибо не получил вообще никаких денег от топракеты:)
Разумеется, вышесказанное не оправдывает топракету, равно как и не дает никаких гарантий при заказе у конечного исполнителя (если таковой вдруг найдется).
Мы скорее это к тому, что именно на этих сайтах если хочется найти что-то приличное, то надо среднерыночный ценник конечного исполнителя умножать на 2-4 и только тогда можно иметь надежду на качество.
ZemAN, если мы правы в данном случае по поводу посредника, то иногда в такой ситуации помогает выход на конечного исполнителя. Который возможно вообще денег еще за работу не видел и исходники все у него. Посмотрите в той верстке что у Вас есть - возможно где-то как-то проскользнут копирайты или еще какой-то намек на его персону.
Чревато:( В прошлом году так платили (лень было 4 раза в год заморачиваться), в результате потом отмахивались от налоговой утверждавшей (разумеется безграмотно и незаконно и свою позицию мы отстояли, но нервы и время) нечто вроде "вычитать из 2,3,4 квартала можно только то что уплачено во 2,3,4 квартале, а то что вы уплатили в 1 квартале вперед, так это Ваша проблема"© Так что лучше поквартально, им привычнее и понятнее.
Вроде можно перенести на след. год, нет? Не знаем точно.
1) Попробуйте запрос вида
SELECT distinct(`browser`),`stream_id`,`source_id`,`service_id`,`user_id`
FROM clients_log
WHERE `user_id`!='0'
2) В любом случае уберите order by null
3) Убедитесь что mysql хотя бы 5.6 версии, а в идеале 5.7. В 5.6 пофиксили много багов с оптимизацией запросов, в 5.7 еще дочистили.
4) Добавьте индекс на browser, user_id или user_id, browser
5) Подумайте о перестройке структуры БД.
При нескольких миллионах записей хранить browser varchar(50) несколько бессмысленно, тем более varchar(50) может обрезать юзер-агента при такой короткой длине. Вынесите browser в отдельную таблицу, оставьте референс в виде browser_id int.
пысы: мы бы начали с пункта 5.
Когда видим фразу "снизилась за счет инфляции" так и подмывает спросить - а что, инфляция это такая магическая штука, что ежегодно в пачку к 100 купюрам еще десять добавляет?
Было у Вас 4млн - могли купить квартиру, сейчас есть 4млн - можете купить квартиру. Снижение это когда Вы можете за те же деньги купить больше квартир.
Не снижаются цены "за счет инфляции" - это последний аргумент, когда уже ну вообще не за что зацепится в аргументации и он негоден.Попробуйте подумать с другой стороны, никто же не говорит что "цена квартиры выросла за счет сдачи в аренду - прибавилось еще 200к за год"? Когда это те же 4млн.
В среднем - потому что товар, а товары растут в цене на инфляцию.
Вообще говоря в основном растет. Даже в сша (которых подкосил кризис) цены уже выше топового 2008 года. Есть исключения - типа греции и испании, но и там уже разворот есть.
