- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Есть каталог товаров, который обновляется раз в неделю. Все товары большинства фирм удаляются и на их место закачиваются новые, описание которых процентов на 90 совпадают с удаленными. Номера ID у новых строк в таблице начинаются от последнего номера предыдущих (удаленных) строк. Также ID используется в ссылке на карточку товара. В итоге каждую неделю у меня будут пропадать тысячи страниц (всё будет вести на страницу «данный товар в настоящее время недоступен») и каждую неделю появляться тысячи новых страниц очень похожих на исчезнувшие. Не уверен, что поисковикам это сильно понравится.
Поэтому появилась мысль после обновления базы, пересчитывать строки. Чтоб ID 2, 5, 8, 15, 27 стали 1, 2, 3, 4, 5. Тогда битых ссылок не будет …правда появятся ссылки которые ведут совсем не на тот товар который был по этой ссылке неделю назад …но наверное это лучше, чем в пустоту.
Ну и собственно сам вопрос: как заставить MySql их перисчитать?
Samail, можно сделать так.
1. Если из базы удаляются все товары, то перед добавлением переустановить значение счётчика:
2. Если не все, то после удаления товаров грохнуть в таблице автоинкрементарное поле и создать его заново.
Думаю было бы логичнее делать уникальные имена товаров и поставить их на ключ unique. Тогда заливка новых записей делать не инсертами, а replace
Удаляются не все, только те, что парсером экспортируются. Те, что вручную добавляются, остаются. Иначе можно было бы просто очищать таблицу.
Сначала скрипт парсит данные в базу на локалке, потом я проверяю и если всё нормально экспортирую таблицу в sql файл который закачиваю уже в базу на сайт. ID при этом, тоже экспортируются и если ID строк совпадают с уже имеющимися, то эти строки не вставляются. А если в дампе счет будет начинаться с единицы, то они обязательно совпадут. Поэтому на локалке, цифры начинаются с больших значений, чем на сайте, чтоб точно не совпали.
В общем, нужно чтоб они как-то уже после добавления пересчитывались.
В общем, нужно чтоб они как-то уже после добавления пересчитывались.
Тогда так, после добавления:
грохнуть в таблице автоинкрементарное поле и создать его заново.
Samail, всё равно непонятно - почему REPLACE не устраивает?
Не создается что-то оно у меня после удаления. :( Только если заново всю таблицу создавать. А автоинкрементарное поле в готовой таблице не создается....
даже если и вернете обратно, все же лучше сделайте как советует товарищ nikitian , потому что для очень большой базы данных серверу придется обновлять огромное число записей сразу, а отсюда сильные нагрузки на сервер при каждом удалении товара
Не создается что-то оно у меня после удаления. :( Только если заново всю таблицу создавать. А автоинкрементарное поле в готовой таблице не создается....
Создаётся. При добавлении необходимо помнить, что оно будет являться первичным ключом, т.е. надо делать так:
alter table имя_таблицы add имя_поля int(11) NOT NULL auto_increment PRIMARY KEY;
Samail, всё равно непонятно - почему REPLACE не устраивает?
Потому что, это списки квартир, составленные несколькими фирмами в нескольких файлах Excel. У них нет ни уникальных номеров, ни уникальных имен. Даже человек не всегда определит, та же это квартира что и в прошлый раз была или нет. Даже если парсер не будет трогать строки, имеющие 100% совпадение с теми, что уже есть в базе. Все равно половина строк будет отличаться циферкой в цене, точкой в сокращении, подправленной опечаткой и т.д. в итоге проблема с увеличившимся значением ID опять всплывет.
Samail добавил 02.06.2009 в 18:30
alter table имя_таблицы add имя_поля int(11) NOT NULL auto_increment PRIMARY KEY;
Вставляется, но последним ...мне желательно, чтоб оно первым в списке было.
Потому что, это списки квартир, составленные несколькими фирмами в нескольких файлах Excel. У них нет ни уникальных номеров, ни уникальных имен. Даже человек не всегда определит, та же это квартира что и в прошлый раз была или нет. Даже если парсер не будет трогать строки, имеющие 100% совпадение с теми, что уже есть в базе. Все равно половина строк будет отличаться циферкой в цене, точкой в сокращении, подправленной опечаткой и т.д. в итоге проблема с увеличившимся значением ID опять всплывет.
Каждая квартира имеет уникальное поле вида crc32(concat(city,"|",street,"|",house,"|",apartmentn)). И не говорите, что нет возможности различать объекты - строители и риэлторы их как-то же разделяют.
Если вместо города, улицы использовать их идентификаторы, то ошибок будет меньше и вообще это лучше. Опять же при добавлении разгребать и функциями вида metaphone, а лучше similar_text, подбирать значения из базы, если нет точного вхождения. Конечно, если вы тупо пихаете все данные от пользователей в базу, то это вам ни к чему - лучше изобрести велосипед.
Люди несовершенны, но компьютеры помогают нам исправлять это.