@IgorO2 ой-ой)) Не прокатило)) Все вариации на тему "впихивания" INSERT/UPDATE/DELETE внутрь запроса SELECT могут караться MySQL-сервером непредсказуемыми последствиями. Единственное решение - использовать несколько запросов одной строкой - для визуального восприятия последовательности действий.
having sum(price) < 100 - в задаче указано "с максимальной эффективностью" - следовательно расчеты необходимо проводить в определённом порядке - одним SQL-запросом не обойтись. Можно конечно поиграться с курсорами, или написать хранимую процедуру - но для удобства понимания логики системы расчета - лучше реализовать средствами языка программирования.
@DonSinDRom вопрос здесь один: Как правильно сделать если заголовок — ссылка? Все остальное - "размышления на тему...". Свои объяснения подкрепляю личным опытом и знаниями, а не "вон как у Яндекса делайте".
@DonSinDRom"Посмотрел исходный код - там..." - там 90% заголовков содержат исключительно текст, единственное исключение - на главной странице рекламная (внешняя - на конференцию) ссылка затесалась в h2. Питер значит))) Видите только то, что хотите увидеть...
Можно таблицы, но "не рекомендуется" (IE сильно извращает отображение - все как обычно). По вариантам: выбираем меньшее из зол)) Ясное дело что плохо, но... Заголовок, по сути своей, осмысленное словосочетание или предложение, являет оглавлением раздела/секции. Логично что ссылкой может быть только весь заголовок, для этого его оборачивают в ссылку. Другой вариант - использовать часть заголовка как ссылку... Видимо по такой же логике поисковики стали сильнее "придираться" и к ссылкам внутри заголовков.
@timathecue не уходя далеко от истины прямо с оф.сайта: "WordPress является идеальной платформой для публикации" - о чем я уже писал (форумы, доски объявлений, новостные сайты).
"принципиальные отличия между магазином и всем остальным" я вижу каждый день в структуре нескольких крупных интернет-магазинов электроники, да и в мелких тоже. Есть список клиентов (или обычных пользователей) у которых есть определенные поля для хранения, данные для сортировка - такие как пол, возраст, адрес проживания и т.п. А теперь внимание - вопрос: если цель нахождения на сайте у этих групп никак не пересекается по функционалу и хранимым данным, какого черта их хранить в одной таблице и относиться к ним как к одной сущности "пользователь"?
Тип сайта/проекта/системы сильно влияет на некоторые принципы разработки - нет на 100% универсальных решений и полностью готовых реализаций.
P.S. Парадокс читать в одном абзаце: "Битрикс - это не авторитетный для меня CMS..." и "...в kohana... это решение из коробки и оно прекрасно работает". Если Вы считаете нормальным использование "решения из коробки" не особо вдумываясь в особенности своего проекта - Вам все же стоит задуматься о карьере в роли разработчика 1С-Битрикс - они единственные кто довели до абсурда "коробочность" своего продукта.
Эммм... Все 4 пары... Гигабит.... Думаю что при "скрутке" и длине кабеля более 40-50 метров будет вставать на 100-T и более не давать... Много факторов - надо проверять. Там ещё наверное 5, а не 5е (и уж точно не 6-я)?
Не ради рекламы, но все их и так знают (1-е строчки Яндекса по запросам "раскрутка" и "оптимизация") - думаю к таким ребятам, пробившимся сквозь толпу конкурентов, стоит прислушаться и присмотреться - ничего лишнего в тегах заголовках H1-H3, только текст: kokoc.com www.optimism.ru
Учитывая "полевые" условия - стойки явно открытого типа ("каркасы"). По кабелю - зависит от расстояния, и планируемой пропускной способности. Конечно если есть возможность - лучше перетянуть)) А так - скрутить и пропаять))
@DonSinDRom с точки зрения HTML оба варианта вложенности возможны. С точки зрения SEO не советую брать пример с Яндекса, как бы странно это не показалось. Можно спорить до бесконечности, но я "озвучил" наиболее логичную версию (+ рекомендации 2-х крупных SEO-компаний, их мнение очень авторитетно, поверьте)
