|
|
|
Аналог merge в MySQL
|
|||
|---|---|---|---|
|
#18+
Есть у меня такая таблица: Код: sql 1. 2. 3. 4. 5. 6. Мне нужно при получении запроса от USER сделать следующее: 1. Если в таблице нет такого USER, добавить новую запись с COUNT=1. 2. Если в таблице есть такой USER и LAST<DATE_FORMAT(CURRENT_TIMESTAMP(), '%Y-%m-01'), то обновить у найденной записи COUNT=1 и LAST=CURRENT_TIMESTAMP(). 3. Если в таблице есть такой USER и LAST>=DATE_FORMAT(CURRENT_TIMESTAMP(), '%Y-%m-01'), то обновить у найденной записи COUNT=COUNT+1 и LAST=CURRENT_TIMESTAMP(). Насколько я понимаю, описание столбца "DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP" решает вопрос обновления поля LAST. Но остается вопрос обновления/добавления поля COUNT, я бы хотел это сделать в один запрос. С помощью MERGE это сделать можно — в предложении WHEN MATCHED я делаю UPDATE, в предложении WHEN NOT MATCHED я делаю INSERT. Но вот с синтаксисом MySQL мне непонятно, как получить такой же результат. Составил такой запрос: Код: sql 1. 2. Но не совсем уверен в его правильности, просьба поправить. ________________________ Мы смотрим с оптимизмом... ...в оптический прицел. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 10:49:32 |
|
||
|
Аналог merge в MySQL
|
|||
|---|---|---|---|
|
#18+
Alibek B., моё ЯТД: 1) не совсем ясен ПК на длинную строку USER. То есть для этой задачи он оптимален, но как ссылка - int, вероятно, все же лучше. А на USER (конкретно для этой задачи) достаточно навесить NOT NULL UNIQUE 2) не верно реализован алгоритм: возможен случай, когда дата перестанет изменяться (в прошлом месяце было одно посещение, тогда при каждом посещении в новом месяце изменения 1 от старого на 1 из нового не произойдет, UPDATE не будет отработано и дата не изменится). Как минимум, в секции UPDATE нужно дописать LAST=CURRENT_TIMESTAMP(). Пруф - по ссылке: ник USR1. 3) добавление (если возможно несколько точек в коде, в т.ч. отладочных) можно оформить процедурой вроде этой ( http://sqlfiddle.com/#!2/c03a3/2 ): Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 22:07:10 |
|
||
|
Аналог merge в MySQL
|
|||
|---|---|---|---|
|
#18+
1. USER у меня это идентификатор пользователя. В основном это будет номер телефона, но иногда это будет email. Есть какая-то выгода сделать его не PK, а просто уникальным ключом? 2. То есть если я сделаю update ... set count=count, то обновления не произойдет, поскольку новое и старое значения совпадают? Ок, запрос подправлю. 3. Я никак не привыкну, что в MySQL наконец добавили ХП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2014, 23:48:35 |
|
||
|
Аналог merge в MySQL
|
|||
|---|---|---|---|
|
#18+
Alibek B., 1) конкретно в этой реализации - ни малейшего. Обычная рекомендация по организации кросс-ссылок: целочисленный ключ а) экономит место в ссылающихся таблицах и собственных индексах, и б) предотвращает ошибки в написании текстовых ключей. Но, конечно, за счет этого несколько увеличивает сложность кода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.06.2014, 08:39:05 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38669467&tid=1834674]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 207ms |
| total: | 368ms |

| 0 / 0 |
