а нельзя сразу?
Но логики тут конечно нет
Холивар на тему что вкусней - селедка или ананасы )))
Берем каталог товаров.
С адовой вложенностью, всякими свойствами и прочей мутью. Позиций на 50000+.
Нормализуем =)
А потом умираем на выборках, джойнах или цикличных прогонах массивов (кому что больше нравится).
Обратная ситуация - берем то же самое, только теперь всю эту муть надо редактировать по 30-50 раз в секунду. Нормализованная база будет вести себя прекрасно.
Да, суть видимо в запарке. Верным решением было добавлять условия в LEFT JOIN ... ON, а не органичивать выборку в последующем WHERE по всей выборке. Т.е. верный вариант будет таким
SELECT col.id as col_id, col.name as col_name, lower(col.url) as col_url, col.baze as col_baze, col.country as col_country, col.producer as col_producer, col.type as col_type, col.images as col_images, col.descr as col_descr, col.minD as col_minD, col.maxD as col_maxD, type.name as type_name, lower(type.url) as type_url, prod.name as prod_name, lower(prod.url) as prod_url, country.name as country_name, lower(country.url) as country_url, base.name as base_name, lower(base.url) as base_url, COUNT(unit.id) as count_unit, Count(upricem.id), Count(uprices.id), MIN(Coalesce(upricem.price,0)) as minpricem, MIN(Coalesce(uprices.price,0)) as minprices FROM _forum_collections as col LEFT JOIN _forum_type as type on (col.type = type.id) LEFT JOIN _forum_producer as prod on (col.producer = prod.id) LEFT JOIN _forum_country as country on (col.country = country.id) LEFT JOIN _forum_base as base on (col.baze = base.id) LEFT JOIN _forum_units as unit on (col.id = unit.col) LEFT JOIN _forum_units as upricem ON ( col.id = upricem.col AND upricem.unit = 'м2') LEFT JOIN _forum_units as uprices ON ( col.id = uprices.col AND uprices.unit = 'шт') WHERE col.id = '1' GROUP BY col.id , col.name, col.url, col.baze, col.country, col.producer, col.type, col.images, col.descr, col.minD, col.maxD, type.name , type.url , prod.name, prod.url, country.name , country.url, base.name, base.url ORDER BY col.name
Спасибо всем ответившим!
нет, не про это. Агрегатные функции игнорируют NULL, а очень хочется, чтобы при LEFT JOIN NULL превращался в 0.
Запрос достаточно активно используемый, поэтому хочется выйти из ситуации с максимально легким для сервера решением.
Если выборки разовые, то проще вариант от _SP_
Если работать постоянно, а еще хуже в реалтайм - то конечно же приводить структуру в порядок, как написал Оптимизайка.
А читать не между строк, религия видимо не позволяет...
Мониторить про яндекс можно сколько угодно.
Очень советую там же обчитаться про:
- передачу ссылочного веса
- инерционность аддурилки
- включение ссылочных факторов для новых страниц
и многое многое другое.
Было предложено:
1 - исправить в базе все урлы на нормальные (второе решение - урленкод от мэд_мэна)
2 - по известному алгоритму соответствия старого урл и нового сообщать яндексу о новом адресе страницы
Тут почему-то все читать начали с п.2
P.S. Не тебе волосы на заднице рвать, а ТС, в случае ошибок. Так посоветуй то, что делал сам и получил положительный результат со всеми вытекающими. А ту воду, про индексацию через аддурилку, можно печатать в персональных блогах про МегаСеоОтВасиПупкина, т.к. страница в индексе с ссылочной массой, ПФ и прочими артибутами ранжирования в разы лучше и интереснее, чем та, которая появится (или не появится) через 2-10 дней (а выкину ка я рваную купюру $100, все равно зарплата через 2-10 дней!), которая получит входящие внутряки после полной переиндексации, с которой те же внутряки уйдут после полной переиндексации, плюс инерция ссылочного ранжирования, накопление ПФ и т.п. В лучшем случае получим равнозначную замену спустя месяц (что врядли). А еще ведь и юзеры, сволочи, будут ломиться на несуществующие страницы с 404 ответом....
Всем удачи )---------- Добавлено 07.11.2014 в 21:43 ----------
Ну так в том и была мысль - чтобы не просто так ходил. Хотя в топике убеждали что пофиг, страниц то уже нет... Страницу то по факту он получает правильную. А по соответствию - можно все спецсимволы резать, можно сравнивать частями, можно расковырять алгоритм замены - вообщем главное чтобы работало.
Mad_Man, senks777, Товарисчи вангующие. Если урлы не в индексе и яндекс их не хочет - он по ним не ходит. В индексе страницы с кривыми ссылками. На типа несуществующие страницы.
Mad_Man, персонально для тебя - здесь никто не хрюкает и не визжит, обоснуй пожалуйста верность своего подхода в контексте вышеозначенной проблемы, а потом рассказывай лекцию про вывод урлов (к методу вопросов нет). Я очень даже дружу с головой, предлагая давать яндексу информацию о том, куда переехала страница которую он запрашивает.
senks777, давай в оптимизаторский раздел свою ересь про два дня для Яндекса и восстановление позиций напиши. У ИМ с 50 000 страниц до года висели в индексе документы со старым урлом, с 404 кодом ответа и висели в топе по СЧ запросам.
Навсегда избавиться от запятой было предложено с самого начала. Вопрос в том, чтобы сообщить боту о том, где нынешний правильный адрес страницы - через 301 редирект. А не говорить о том, что такой страницы нет, вернее есть, но ты догадайся сам где.
Ссылочная составляющая между внутряками так же не моментально расчитывается ботами. И даже при 301 редиректах возможны проседания. Вы же человеку предлагаете просто новый сайт сделать с точки зрения ПС со всеми вытекающими.
postavkin,
Гугл посоветует использовать canonical
Отлично. Есть страница, по кривому урл. Есть страницы, ссылающиеся на кривой урл. Все это торчит в базе ПС. Убиваем старый урл. Напрочь и везде, выдаем 404 страницу. Засекаем время, через сколько будут проиндексированы новые страницы, расчитан вес ссылок на нее и т.п.
Вариант 2. Подготавливаем костыли для нахождения нужной страницы по кривому урл и 301 редиректу на страницу с новым, правильным урл.
P.S. Вы тут конечно все жутко мудрые программеры, но с точки зрения оптимизации и поискового продвижения просто изменение урлов - огромная гадость. Перед такими советами, опробуйте на своих действующих и раскрученных сайтах данные методики, а потом расскажите, через сколько роботы найдут новые страницы и как они их отранжируют.
Все верно, кроме того что в индексе уже валяется куча страниц. А ты предлагаешь экранировать символы - то есть прописывать все эти страницы на новые адреса с точки зрения ПС. И задача ТС в первую очередь не потерять эти страницы.
