Форум MySQL

Таблица rating_sum содержит поля id, str, pos, prod, в которых хранится информация об идентификаторе, имене страницы, количестве её посетителей и количестве продаж с этой страницы за все время набора статистики ДО сегодняшнего дня.

В таблице rating_seg содержится та же информация, но только ЗА сегодняшний день.

И возникает задача прибавить содержимое строк таблицы rating_seg к содержимому строк таблицы rating_sum.

Для этого я поочередно перебираю все строки таблицы rating_seg и для каждого значения имени страницы str ищу строку с этим именем в таблице rating_sum.

Если такой строки в таблице rating_sum нет, то создаю в этой таблице новую строку и заношу в нее данные str, pos и prod из таблицы rating_seg.

Если в таблице rating_sum строка с именем str есть, то считываюиз нее значения pos и prod, прибавляю к каждому из них соответстсвующее значение из таблицы rating_seg и обновляю содержимое этой строки в таблице rating_sum.

Всё это не только муторно, но и чрезввычайно долго, а при большом количестве страниц не работоспособно вообще. Поэтому возникает необходимость как-то оптимизировать этот процесс, избавившись от циклического перебора десятков тысяч страниц.

Как бы это осуществить?

Нет такой возможности?

Ммм… А что Вам мешает сделать это все в одной таблице..?
Прибавлять как за сегодня, так и всего, а в нужное время просто обнулить все счетчики за сегодня?

Первоначально я так и делал, записывая всю информацию в реальном времени.
Но потом, когда количество строк стало приближаться к ста тысячам, пришлось перейти к суточному архивированию для исключения замедления открытия сайта.

тогда наверно надо использовать

INSERT INTO   `tbl` (...) SELECT   (...)  FROM `tbl_2`  ON DUPLICATE KEY UPDATE ...

в одной таблице на id ставите первичный ключ,
во 2ой табл. на id ставите уникальный ключ

хм.. а на второй почему первичный не поставить?

ну... даже не знаю. я как то привык так делать.
если таблицы одинаковые, то все равно пытаться делать одну зависимой от другой..
а для чего в обеих таблицах такие ключи?

Такая задача у меня встречается очень часто, и потому очень хотелось бы научиться ее корректно решать.

Не могли бы Вы объяснить это поподробнее?

у Вас есть поле `str` - это как я понял название страницы. так?
оно у Вас уникально?

Просто по id группировать и переносить, скорее всего, будет неправильно.

Т.к. Вы хотите одну таблицу сделать маленькой.. и после переноса полностью очищать.. так?

Тогда при записи, Вам придется ориентироваться по 2ой таблице, чтоб узнать id той или иной записи.. В чем и получаем еще хуже эффект.

Вам надо по URL или по названию, лучше использовать их хэш, записывать в маленькую.. а потом все переносить, и если такой же хэш уже будет в основной табл., просто прибавлять счетчики.. если нет, то записываем как новую запись…

ну.. я бы так сделал.. не знаю, насколько это правильно..

уникальный ключ позволит Вам добавлять в таблицу строки с незаданным (null) значением ключа.
первичный - не позволит.
Фактически здесь отношение 1:1 - значит в обеих таблицах ключ можно объявить первичным.
Понятно, что минимум в одной из них он тут же окажется чужим - там где будет не задаваться auto_increment, а браться из другой таблицы..

т.е. Вы хотели сказать, что надо дать и там и там первичный ключ, но только в одном использовать auto_increment?

но все же до меня не доходит как-то.. если в первой стоит первичный + auto_increment, то мы уже избегаем попадания id = NULL
или я что-то не понял...

>т.е. Вы хотели сказать, что надо дать и там и там первичный ключ, но только в одном использовать auto_increment?
да.

>но все же до меня не доходит как-то.. если в первой стоит первичный + auto_increment, то мы уже избегаем попадания id = NULL

избегаем при вставке новой записи, но никак не при update

Кроме того избегать-то избегаем, но и требуемое значение тоже не помещаем, а это ничуть не лучше.

Да, в этом Вы правы.
=) как всегда..

Думал-думал я целый час, но так и не врубился: да, str представляет собой имена страниц и этот параметр уникален, а потому его можно использовать как ключ, связывающий обе таблицы некоей закономерностью. Можно то можно, но как? Каким все-таки образом формируется запрос-обновление? Вот что практически то?

ну..сделайте поле `hash_title` varchar(32) UNIQUE KEY
и записывайте туда md5($title)

Я не про тайтлы. Я про то, как предложенный Вами код

INSERT INTO    `tbl` (...)  SELECT    (...)   FROM `tbl_2`   ON DUPLICATE KEY UPDATE

из его общего вида превратить в практически действующий.

Я Вам и говорю, чтоб сработал
ON DUPLICATE KEY UPDATE
надо уникальное поле. по id я Вам описал почему не стоит делать...
поэтому используйте хэш тайтла..

Так я ничего и не понял..
Похоже, не судьба.