|
| |
|
|
| |
для: а-я
(23.03.2009 в 19:40)
| | | Так я ничего и не понял..
Похоже, не судьба. | |
| |
|
|
| |
|
|
| |
для: Владимир55
(23.03.2009 в 19:23)
| | | Я Вам и говорю, чтоб сработал
ON DUPLICATE KEY UPDATE
надо уникальное поле. по id я Вам описал почему не стоит делать...
поэтому используйте хэш тайтла.. | |
| |
|
|
| |
|
|
| |
для: а-я
(23.03.2009 в 16:58)
| | | Я не про тайтлы. Я про то, как предложенный Вами код
INSERT INTO
`tbl` (...)
SELECT
(...)
FROM `tbl_2`
ON DUPLICATE KEY UPDATE
|
из его общего вида превратить в практически действующий. | |
| |
|
|
| |
|
|
| |
для: Владимир55
(23.03.2009 в 16:32)
| | | ну..сделайте поле `hash_title` varchar(32) UNIQUE KEY
и записывайте туда md5($title) | |
| |
|
|
| |
|
|
| |
для: а-я
(23.03.2009 в 16:19)
| | | Думал-думал я целый час, но так и не врубился: да, str представляет собой имена страниц и этот параметр уникален, а потому его можно использовать как ключ, связывающий обе таблицы некоей закономерностью. Можно то можно, но как? Каким все-таки образом формируется запрос-обновление? Вот что практически то? | |
| |
|
|
| |
|
|
| |
для: Trianon
(23.03.2009 в 16:08)
| | | Да, в этом Вы правы.
=) как всегда.. | |
| |
|
|
| |
|
|
| |
для: а-я
(23.03.2009 в 15:56)
| | | >т.е. Вы хотели сказать, что надо дать и там и там первичный ключ, но только в одном использовать auto_increment?
да.
>но все же до меня не доходит как-то.. если в первой стоит первичный + auto_increment, то мы уже избегаем попадания id = NULL
избегаем при вставке новой записи, но никак не при update
Кроме того избегать-то избегаем, но и требуемое значение тоже не помещаем, а это ничуть не лучше. | |
| |
|
|
| |
|
|
| |
для: Владимир55
(23.03.2009 в 15:00)
| | | у Вас есть поле `str` - это как я понял название страницы. так?
оно у Вас уникально?
Просто по id группировать и переносить, скорее всего, будет неправильно.
Т.к. Вы хотите одну таблицу сделать маленькой.. и после переноса полностью очищать.. так?
Тогда при записи, Вам придется ориентироваться по 2ой таблице, чтоб узнать id той или иной записи.. В чем и получаем еще хуже эффект.
Вам надо по URL или по названию, лучше использовать их хэш, записывать в маленькую.. а потом все переносить, и если такой же хэш уже будет в основной табл., просто прибавлять счетчики.. если нет, то записываем как новую запись…
ну.. я бы так сделал.. не знаю, насколько это правильно.. | |
| |
|
|
| |
|
|
| |
для: Trianon
(23.03.2009 в 15:04)
| | | т.е. Вы хотели сказать, что надо дать и там и там первичный ключ, но только в одном использовать auto_increment?
но все же до меня не доходит как-то.. если в первой стоит первичный + auto_increment, то мы уже избегаем попадания id = NULL
или я что-то не понял... | |
| |
|
|
| |
|
|
| |
для: а-я
(23.03.2009 в 14:36)
| | | уникальный ключ позволит Вам добавлять в таблицу строки с незаданным (null) значением ключа.
первичный - не позволит.
Фактически здесь отношение 1:1 - значит в обеих таблицах ключ можно объявить первичным.
Понятно, что минимум в одной из них он тут же окажется чужим - там где будет не задаваться auto_increment, а браться из другой таблицы.. | |
| |
|
|
|
