|
|
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
Добрый день. Скажите пожалуйста какой смысл делать два UNIQUE INDEX по одним и тем же столбцам но в разной последовательности? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 19:58 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
Olegush, От перестановки мест слагаемых, уникальность не меняется. А порядок разный может потребоваться для удовлетворения разных условий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 20:27 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
-2-, авторОт перестановки мест слагаемых, уникальность не меняется. А порядок разный может потребоваться для удовлетворения разных условий. То что уникальность не меняется я знаю. Вопрос был есть ли смысл именно два уникальных индекса иметь. И про удовлетворения разных условий я тоже знаю, вопрос - зачем именно уникальные сделали а не скажем один уникальный и один обычный? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 20:35 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
Olegush, трудно что-то сказать, не зная деталей... Может для уменьшения размера индекса Код: 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. правда это добавляет оверхед на проверках уникальности при insert/update. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 22:16 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
xtender добавляет оверхед на проверках уникальности при insert/update.не факт, что декларация unique влияет на процесс изменения индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2018, 23:06 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
-2-А порядок разный может потребоваться для удовлетворения разных условий. Для поиска по различным сочетаниям вполне достаточно будет обычных индексов по составу полей, в который не входит хотя бы одно поле, входящее в состав полей уникального индекса.индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 01:14 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
-2-декларация unique влияет на процесс изменения индексапо-моему, это вполне очевидно, особенно, если в одной сессии удалить запись и не коммитить, а в другой попробовать вставить такие же значения. зы. отдельно это можно сравнить с другим вариантом: если в одной сессии удалить вставить запись и не коммитить, а в другой попробовать вставить такие же значения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 01:20 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
ПС. Смысл создавать именно так поля вижу только для такого кейса: Уникальным является сочетание (a,b), но будут извлечения значения <a> при поиске только по <b>, и для того чтобы оракл мог извлекать <a> напрямую из сегмента индекса, без чтения сегмента таблицы, и сделали индекс над (b, a). А уникальным его сделали хз зачем, на всякий случай, видимо ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 01:20 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
d.nemolchev-2-А порядок разный может потребоваться для удовлетворения разных условий. Для поиска по различным сочетаниям вполне достаточно будет обычных индексов по составу полей, в который не входит хотя бы одно поле, входящее в состав полей уникального индекса.индекса. если чисто гипотетически, то предикаты разные бывают, например, есть уникальные индексы на (a,b) и (b,a) есть такие наборы предикатов: 1. a in (:a1,:a2,:a3) and filter(b) = :fb 2. b in (:b1,:b2,:b3) and filter(a) = :fa если из какого-нибудь из этих индексов убрать одно поле, например из уникального (b,a) сделать просто на b, то во втором варианте фильтр перейдет на таблицу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 01:26 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
ну и помимо этого диапазонные поиски по 1. a=:a and b between :b1 and :b2 2. b=:b and a between :a1 and :a2 будут не так эффективны. Но это все гипотетически, в реальной жизни я такой необходимости еще не встречал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 01:31 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
xtender, я имел ввиду случай, когда к таблице обращаются ограниченным кол-вом запросов типа 1. select ... where a = :a1 2. select a from ... where b = :b1 для случая 2 при наличии индекса над (b,a) обращения же к сегменту таблицы не будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 01:47 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
d.nemolchev-2-А порядок разный может потребоваться для удовлетворения разных условий.Для поиска по различным сочетаниям вполне достаточно будет обычных индексов по составу полей, в который не входит хотя бы одно поле, входящее в состав полей уникального индекса.индекса.select a from t where b = :b; -- оптимальный индекс b, a и select b from t where a = :a; -- оптимальный индекс a, b xtender-2-декларация unique влияет на процесс изменения индексапо-моему, это вполне очевидно, особенно, если в одной сессии удалить запись и не коммитить, а в другой попробовать вставить такие же значения.Вполне очевидно, что вопрос уникальности это бизнес-требования. Приведенную тобой ситуацию неправильно рассматривать как "оверхед". Рассматривать оверхед от указания unique нужно в контексте дублирующего индекса или одного индекса, когда обеспечивается естественная уникальность. Только в этом случае допустим выбор между указывать или не указывать unique. Утверждаю, что такого оверхеда нет. Если один и тот же индекс (не)указать unique, на время вставки и апдейта уникального ключа это не повлияет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 08:38 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
-2-, where b = :b; -- оптимальный индекс b, a Он оптимален если выбирается только <а>. А если там ещё и другие поля вытаскивают, то включение в состав индекса поля <а> Избыточно и бессмысленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 09:29 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
d.nemolchevА если там ещёа если еще и в where нет условия по b, то жизнь бессмысленна и беспощадна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 09:34 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
-2-Приведенную тобой ситуациюммда... вообще-то я имел ввиду не сами блокировки, а просто показал, что с уникальными индексами вызывается дополнительный код проверки уникальности - он не может быть бесплатным. -2-Утверждаю, что такого оверхеда нет. Если один и тот же индекс (не)указать unique, на время вставки и апдейта уникального ключа это не повлияет. например так Код: 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. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 09:45 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
xtenderнапример такэто специфичный тест, связанный со значительным увеличением размера ключа. В случае неуникального индекса увеличение ключа играет значительно меньшую роль на фоне размера rowid. Исходный insert level у меня дал: 00:00:03.572 и 00:00:08.440 (u). Если в исходном инсерте вставлять большие значения, то разница уже в пределах погрешности. insert level+1e6: 00:00:01.982 и 00:00:01.965(u) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 10:13 |
|
||
|
Oracle UNIQUE INDEX
|
|||
|---|---|---|---|
|
#18+
-2-вставлять большие значенияпросто тогда нивелируется разница за счет выигрыша в размере индекса. а вот с большими так: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2018, 10:42 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39626442&tid=1884179]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
62ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 413ms |

| 0 / 0 |
