|
|
|
CHECK CONSTRAINT иногда не срабатывает.
|
|||
|---|---|---|---|
|
#18+
Есть таблица: Код: plsql 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. Смысл этого CHECK CONSTRAINT в том, что в таблице значения в колноках portid1 и portid2 должны быть различны, то есть если в колонке portid1 уже присутствует какое-то значение, то оно уже не может появится ни в колонке portid1, ни в колонке portid2, аналогично и для portid2. Я написал данный constraint, проверил его с помощью простых INSERT и UPDATE - работает. Однако, сегодня обнаружил в таблице вот такой набор записей: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Пробовал сделать Insert с этими же portid, constraint отрабатывает, не получается вставить запись. Попробовал удалить constraint, повесить заново - не получилось, то есть никто не мог удалить constraint, вставить записи и снова повесить. Как оказалось такая ситуация не единичная. Подскажите, как такое могло получится? Потому что я использую SELECT в constraint? И как сделать правильно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 07:45 |
|
||
|
CHECK CONSTRAINT иногда не срабатывает.
|
|||
|---|---|---|---|
|
#18+
Параллельность, транзакции, их изоляция и типа все такое. Код: sql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 08:13 |
|
||
|
CHECK CONSTRAINT иногда не срабатывает.
|
|||
|---|---|---|---|
|
#18+
Как сделать правильно точно не скажу. Придумал вариант -- два уникальных индекса по выражению: Код: sql 1. 2. 3. Приведенный выше пример с дублированием уже не проходит. Вторая транзакция начинает ждать окончания первой, и в зависимости от нее либо завершаться нормально, либо выдавать ошибку. Дублей не появляется. А вообще-то задача вызывает подозрение на ошибку в проектировании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 08:29 |
|
||
|
CHECK CONSTRAINT иногда не срабатывает.
|
|||
|---|---|---|---|
|
#18+
Alexander A. SakКак сделать правильно точно не скажу. Придумал вариант -- два уникальных индекса по выражению: Код: sql 1. 2. 3. Спасибо, мне тоже похожее решение подсказали: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Только еще check приходится использовать. Alexander A. SakПриведенный выше пример с дублированием уже не проходит. Вторая транзакция начинает ждать окончания первой, и в зависимости от нее либо завершаться нормально, либо выдавать ошибку. Дублей не появляется. А вообще-то задача вызывает подозрение на ошибку в проектировании. Да, похоже на ошибку в проектировании, я специально показал еще FOREIGN KEY, чтобы было понятно, что из себя таблица представляет. То есть это порты оборудования, которые могут быть соединены между собой, естественно, один порт дважды соединен быть не может. Я так понимаю правильней было бы не создавать таблицу link, а просто добавить поле link_to в табличке snmp_ports? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 08:43 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38923295&tid=1998072]: |
0ms |
get settings: |
6ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
183ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 197ms |
| total: | 482ms |

| 0 / 0 |
