|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Есть таблица: Код: plsql 1. 2. 3. 4. 5. 6. 7.
Для STATUS=1 комбинация (TYPE_ID,CODE) должна быть уникальной. Для STATUS=0 уникальность не требуется (точнее ее не будет, будут повторы CODE для одинакового TYPE_ID). Как тут лучше сделать? Неуникальный индекс по TYPE_ID,CODE и ручная проверка STATUS? Вычисляемый индекс по TYPE_ID,CODE,nullif(STATUS,0)? Уникальный индекс по TYPE_ID,CODE и обновление статуса таким образом: update PINS set STATUS=0, COPY=CODE, CODE=null where ... ? (в последних двух вариантах я исхожу из того, что null не индексируется) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2019, 22:18 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#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. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56.
SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2019, 22:59 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Alibek B. Вычисляемый индекс по TYPE_ID,CODE,nullif(STATUS,0)? Уникальный индекс по TYPE_ID,CODE и обновление статуса таким образом: update PINS set STATUS=0, COPY=CODE, CODE=null where ... ? (в последних двух вариантах я исхожу из того, что null не индексируется) У тебя неправильное понятие null не индексируется. Не индексируются записи у которых значения всех индeксных выражений NULL. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2019, 23:08 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Понял, спасибо. А как при этом должен быть сформирован запрос, чтобы этот индекс использовался? where STATUS = 1 and TYPE_ID = ... and CODE = ... ? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2019, 23:10 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
SY У тебя неправильное понятие null не индексируется. Не индексируются записи у которых значения всех индeксных выражений NULL. Да, я уже это понял на экспериментах и примеры нашел, у меня сейчас индекс такой: Код: plsql 1. 2.
Видимо немного перепутал с MSSQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.11.2019, 23:13 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6.
или первый CASE - range scan, или второй CASE - skip scan. SY. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 00:57 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Alibek B. А как при этом должен быть сформирован запрос, чтобы этот индекс использовался? where STATUS = 1 and TYPE_ID = ... and CODE = ... ? Выражения индекса, по-правильному, нужно описывать явными виртуальными колонками, а вместо индекса создавать нормальное ограничение уникальности. Тогда проблем с "как писать запрос?" не возникнет. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 07:45 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
А если использовать такой индекс: TYPE_ID, CODE, decode(STATUS,1,ID) ? ID всегда уникален (это sequence). На мой взгляд использовать такой индекс проще и функции ограничения он так же будет выполнять. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 08:08 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Сделал так: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
На тестовых данных ведет себя, как мне и надо — разрешает дубли при STATUS!=1. Но судя по explain, индекс не используется, пока в where я не укажу все три выражения: Код: plsql 1. 2. 3.
Если последнее (с decode) не указывать (или указать просто status=1), то в плане TABLE ACCESS FULL. Это из-за маленького размера таблицы или для уникального индекса Oracle не будет использовать часть индекса? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 09:13 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Alibek B.А если использовать такой индекс: TYPE_ID, CODE, decode(STATUS,1,ID) ?Ну а сам как думаешь? Alibek B.ID всегда уникален (это sequence).А его не было в исходном вопросе. Alibek B. На мой взгляд использовать такой индекс проще ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 09:20 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Мне нужно часто проверять записи по критерию: type_id=<type> and code=<code> and status=1. Было бы удобнее всего, если бы и в SQL-запросе указывался аналогичный фильтр. Но и так это удобнее, чем использовать case/decode для type_id и code. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 09:32 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
Alibek B. Но и так это удобнее, чем использовать case/decode для type_id и code. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 09:39 |
|
Составной ключ для определенных записей
|
|||
---|---|---|---|
#18+
У меня Oracle 10g, в нем их нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.11.2019, 09:58 |
|
|
start [/forum/topic.php?fid=52&msg=39885097&tid=1881908]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
74ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
others: | 15ms |
total: | 191ms |
0 / 0 |