dimidrol

dimidrol
Рейтинг
191
Регистрация
29.09.2005
kot77:
Добрый!

Регистрируем домен xxx-xx-xx.ru, где имя домена схоже до степени смешения с соответствующим прямым номером телефона. В рамках одного региона, естественно :)

CTR падает а звонки идут, особенно в горячих тематиках.
Вопрос к знатокам: какова статистика затрат на подобную кампанию? как правильно играть в этом случае для снижения расходов?

никак. 10 никаков.

копия без согласия правообладателя - это подделка, и точка. за это и банят нещадно.

тематика? что за тематика?

и зачем эти заморочки с сейшелами?!

Дабы не создавать новый топик. Вводные: ссылками не торгую, все сайты в вебмастере висят на одном аккаунте.

Есть 2 сайта, у них пересекающейся список запросов.

сайт1: слово1+слово2+слово3 + хвосты

сайт2: слово1+слово3 + хвосты

оба по запросу "слово1+слово3" висят в топ 10 (сайт2 выше сайт1). но сайту 1 там делать совсем нечего, более того там "мы палимся" 😂.

Вопрос: нужно ли сообщать яндексу о такой фигне дабы он не выкинул в последствии тот, который как раз нужен?

нарисовать, самый простой вариант

masskill:
Наполнение сайтов и рутинная работа это 2 разные части, которые у нас делают 4 разных человека 🙅

Чукча приехал домой из Москвы и говорит: "Чукча в Москве был, Чукча умным стал, все знает: Оказывается, Карл, Маркс, Фридрих, Энгельс не четыре человека, а два, а Слава Кпсс - вообще не человек."
bsyomov:
Если надо получить результат с сортировкой по нужному полю, сделать по нему индекс, и делать запросы с нужной сортировкой. Это не накладнее, чем выборка по id. Зачем вам id менять при этом? Всё же подумайте над постановкой задачи сначала, т.е. зачем вам менять id.

уже подумал и иного варианта нет.

Есть таблица. В ней есть поле id, которое является auto_increment и unique. Сейчас в таблице огранизовалась следующея ситуация


id ... num ... posted
1 4 1000000
2 6 1000001
3 3 1000002

Задача - привести таблицу к новому виду без создания временной таблицы


id ... num ... posted
1 3 1000002
2 4 1000000
3 6 1000001

при решении "в лоб" (Select с сортировкой по num и update на поле id) вызывает

Invalid query: Duplicate entry '1' for key 'PRIMARY'

т.к. в первой итерации получается


id ... num ... posted
1 4 1000000
2 6 1000001
1 3 1000002
stifler_x:
Может вместо DESC попробуйте ASC :)

да не важно в каком направлении сортируется. важно не получить

Invalid query: Duplicate entry '1' for key 'PRIMARY'
LEOnidUKG:
Что ещё за слово перетасовать? Осортировать вам нужно по полю num что-ли?

да

stifler_x:
Что такое поле num?

integer

Всего: 1210