Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
массовый update
|
|||
|---|---|---|---|
|
#18+
добрый день подскажите как решить проблему мне нужно в таблице, в одной из ключевых колонок увеличить все значение на 2, когда делаю update table set felds=fields+2 выдает duplicate key, что вообще то логично я так понимаю надо на время выполнения запроса отключить котроль этот как это можно сделать? когда то давно видел на тут упоминание, но не могу найти :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.04.2005, 11:46 |
|
||
|
массовый update
|
|||
|---|---|---|---|
|
#18+
Это косяк древний. Если поискать , то это оправдывают тем, что отложенная проверка уникальности будет сильно тормозить. Там же несколько рецептов приводится (например упорядочить физически строки по убыванию ключевого поля, или ходить циклом в порядке убывания). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2005, 04:33 |
|
||
|
массовый update
|
|||
|---|---|---|---|
|
#18+
Проверенно: в Firebird те же грабли. И с INSERT ... SELECT (см. в Google по ссылке выше) тоже. Видимо в чем-то дизайн совпадает Ж-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2005, 14:06 |
|
||
|
массовый update
|
|||
|---|---|---|---|
|
#18+
По идее, везде одинаково должно быть, во всех базах. Проход в порядке убывания должен спасать (если ещё кто-то не работает в базе, естественно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2005, 15:43 |
|
||
|
массовый update
|
|||
|---|---|---|---|
|
#18+
ффффЭто косяк древний. Если поискать , то это оправдывают тем, что отложенная проверка уникальности будет сильно тормозить. Там же несколько рецептов приводится (например упорядочить физически строки по убыванию ключевого поля, или ходить циклом в порядке убывания). отложенная праверка уникальнасти не праблема (с логической точки зрения). действительная логическая праблема - каскады (по вторичным), если они там будут (1 ->2, 2->3). Т.ч. это не косяк, или "не совсем касяк". Можно ли проблему каскда решить с помощью разделения "областей видимости" (т.е. чтобы каскады при отработке видели только записи до начала транзакции)? Наверное можно (не будет ли там, в такой логике, т.е., смежных проблем в сложных взаимных транзакциях?). Но не очевидно, что можно именно в постгресе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2005, 16:49 |
|
||
|
массовый update
|
|||
|---|---|---|---|
|
#18+
4321 отложенная праверка уникальнасти не праблема (с логической точки зрения). действительная логическая праблема - каскады (по вторичным), если они там будут (1 ->2, 2->3). Т.ч. это не косяк, или "не совсем касяк". Для суррогатного первичного ключа, который никогда не изменяется это как раз не проблема. А вот для unique constraint или уникального индекса - это актуально. Я согласился бы что это не баг а фича, если бы от физического порядка строк (т.е. ctid) не зависело, пройдет update или нет. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. А насчет того, что INSERT .. SELECT .. WHERE NOT EXISTS() обламывается если в другой сессии вставили запись - это для версионника как раз нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2005, 03:46 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=343&tid=2007290]: |
0ms |
get settings: |
10ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 367ms |

| 0 / 0 |
