|
|
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
Всё равно у тебя запрос неправильный. Дай наполнение таблицы инсертами, что-бы не мучатся. Я у себя посмотрю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 14:55 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
Чем он неправильный? Религией? :) Наполнение таблицы инсертами - самый тупой вариант: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Тогда, когда я с этим приколом впервые столкнулся (начало 2001 г.), в таблице было как раз примерно 70000 записей. Задача - обновить значение поля ksi_j до некоего рандомического числа в диапазоне (-1, 1) для примерно 1/7 части записей за каждый запуск процедуры. На самом деле, таблица была сложнее, но у меня, к сожалению, не осталось с того времени ничего, восстановил по моментам переписки. Но это не суть, ибо глючит и в приведённом выше варианте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 15:01 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
Попытаюсь обьяснить в чём твоя ошибка: вот это выражение trunc(dbms_random.value(1, 7)) = 1 вычисляется всего один раз еще при грамматическом разборе, до выполнения запроса. Определение случайного числа не происходит для каждой строки запроса. Поэтому если в момент разбора значение функции совпадёт со значением 1 - тогда запрос должен вернуть все строки, если не совпадёт то ни одной. Попробуй просто повыполняй несколько раз этот запроса и сам убедишься Код: plaintext 1. У тебя будет или 0 записей или все - других вариантов не будет. Если же рассуждать что вызов dbms_random.value происходит для каждой строки, то какой-то строки совпадёт, какой-то нет, в этом случае кол-вот строк может быть каким угодно от 0 до кол-ва строк в таблице. Реально же получается только 0 или count(*). Вот так вот. Так что никакого бага или глюка здесь нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 16:00 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
Вызов dbms_random.value в моей конструкции будет происходить для каждой строки таблицы, т.е. 70000 раз. Это легко подтверждается как прогоном процедуры на таблице с ключом, так и таким тестом (таблица - с ключом): Код: 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. Здесь видно, что верно предположение о том, что из 70000 последовательно взятых случайных чисел примерно 1/7 часть будет находится в диапазоне [1, 2). А вот если грохнуть ключ, то, действительно, очень похоже на то, что dbms_random.value вызывается реально только один раз. Если же ключ не удалять, а задисаблить, запрос подвисает :( Спрашивается - чем обусловлено такое поведение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 17:11 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
План запроса надо смотреть. Когда подключается индекс - меняется план запроса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 17:15 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
Код: 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. Пока не ясно, почему изменение плана выполнения влияет на результаты запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 17:24 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
А команда создания ключа какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 17:39 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
спасибо за ответы, к сожалению не мог отвечать раньше .dba а почему не устраивает просто PRIMARY KEY (b, created) ? Ну будет ключ на несколько байт больше, ну и что? "b_num уникальны в пределах года", а твой PRIMARY KEY (b_num, created) это обеспечивает??? уникальны в пределах года - значит, что нельзя вставить два одинаковых номера b_ num для дат created одного года Код: plaintext 1. ну а так - понятно - можно Код: plaintext 1. softbuilder@inbox.ru Толковые разработчики делают так: в каждой таблице добавляется дополнительный столбец, который используется именно как первичный ключ и никакой другой информативности не несёт и логически с другими столбцами никак не связан. Значение столбца берётся из сиквенса при каждой вставке новой строки. Вот и всё. да не совсем всё. я конешно знаю про id, который берется из sequence в триггере BEFORE INSERT, такие ключи у меня есть в 80% таблиц. но вообще-то этот ключ мне нужен был для реализации правила "номер объекта уникален в пределах года" и организации ссылочной целостности в уже существующей таблице, изменять структуру которой нежелательно Scott Tiger Кстати, query rewrite с какой версии появился? У меня на 8.1.7EE, например, вполне проходит вариант Код: plaintext 1. 2. а что такое query rewrite? у меня такое не проходит: Код: plaintext 1. 2. 3. на что документация говорит Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 18:15 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
2softbuilder: самая простая Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 18:30 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
2whois: По поводу query rewrite см. Oracle8i Data Warehousing Guide, для 8.1.6 это глава 19. Даёт, в том числе, возможность использования функциональных индексов. Надо в pfile поставить query_rewrite_enable = true и дать grant query rewrite to <user> Кстати, для вставки инкрементирующихся значений триггерами лучше не пользоваться, лучше честно вызывать sequence_name.nextval. А вот если query rewrite у тебя не работает, то разве что триггером можно будет реализовать такое ограничение целостности при вставке и обновлении, не изменяя структуры таблицы. Если у тебя много insert-ов, лучше будет изменить структуру, если мало - приделать триггер, в любом случае проапгрейдить 8.1.5 - версия кривая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.01.2003, 18:51 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
2Scott Tiger: спасибо за прояснение ситуации. конечно, query rewrite - наш выбор ))), но и на 8.1.5 можно исхитриться - 8.1.5 также позволяет создавать функциональные индексы (Function-based Index): Код: plaintext 1. 2. 3. создаем функцию с директивой DETERMINISTIC: Код: plaintext 1. 2. 3. 4. и далее: Код: plaintext 1. 2. ну это уже хоть что-то )), хотя PRIMARY KEY (b_num, year(created)) и UNIQUE (b_num, year(created)) продолжают ругаться: Код: plaintext 1. 2. 3. теперь Код: plaintext 1. 2. 3. 4. 5. 6. 7. по поводу апгрейда 8.1.5 PE до 8.1.6, 8.1.7 - так понимаю, что "поверх" поставить нельзя, нужно искать дистрибутив? и прокатит ли просто подложить ему старые файлы бд и создать новую службу: oradim -new -sid MYSID -intpwd ******** -startmode manual -pfile X:\Oracle\admin\MyDB\pfile\init.ora? Кстати, для вставки инкрементирующихся значений триггерами лучше не пользоваться, лучше честно вызывать sequence_name.nextval. мммм. что именно ты имеешь ввиду? вызывать откуда? я делаю так: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2003, 17:54 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. К сожалению, с 8.1.5 такой фокус (со старыми файлами) не пройдёт -- нужно мигрировать. Но дистрибутив 8.1.5 тебе для этого не нужен. Вот файлы от 8.1.6 уже можно в лоб апгрейдить до 8.1.7.х Код: plaintext 1. 2. 3. Вот именно так и не советовали делать. Имелось ввиду, что правильнее выбирать seq.nextval в самом операторе вставки: Код: plaintext А в триггере оставить только защитную логику (на NULL значение PK). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.01.2003, 20:38 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
А почему нельзя просто CREATE OR REPLACE TRIGGER trg_b_ins BEFORE INSERT ON b FOR EACH ROW BEGIN new.created = TRUNC(sysdate,'YYYY'); END trg_b_ins; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2003, 07:10 |
|
||
|
сложный PRIMARY KEY
|
|||
|---|---|---|---|
|
#18+
to SERG1257 в данном случае created обязательно должно хранить фактическую дату записи, а не только год. триггерами-то конешно можно, только тебе надо еще проверять отсутствие номера в пределах года. смысл был в использовании встроенных механизмов обеспечения целостности. ты же не реализуешь, например, обычный первичный ключ как-то вручную, триггерами или еще как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.01.2003, 17:11 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=32096179&tid=1991991]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
150ms |
get topic data: |
8ms |
get forum data: |
7ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 466ms |

| 0 / 0 |
