безопасно выполнять select by rowid

Интересно, можно ли использовать rowid для сопоставления строк?безопасно выполнять select by rowid

Я следующий запрос:

select * from a, 
    (select a.rowid rid, <some_columns_omitted> from a, b, c where a.some_column = b.some_column ... <joining_omitted> 
    union all 
    select a.rowid rid, <some_columns_omitted> from a, d, e where a.some_column = d.some_column ... <joining_omitted> 
    union all ....) sub_query 
where a.rowid = sub_query.rid

ли с помощью rowid для сравнения строк быть в безопасности, как с использованием первичного ключа?

источник

2013-09-04 michael nesterenko

его странный запрос честно. Скорее всего, вы также вернете дубликаты, так как вы делаете союз в суб-запросе (у суб-запроса, скорее всего, будет несколько строк одного и того же rowid). Объединение или использование IN решат это, но попробовали ли вы просто подключиться к другим таблицам по мере необходимости? – tbone

@tbone, я использую такой запрос, потому что мне нужны данные из других таблиц, например. 'D'. Нет дубликатов из-за условий в подзапросах, они не совпадают с дубликатами. Я не могу переместить союз из подзапроса, потому что в реальном запросе мне нужно заблокировать данные, и я использую предложение 'for update', которое не работает с объединением –

Смотрите этот родственный вопрос:

Oracle ROWID as function/procedure parameter

Oracle гарантирует, что, до тех пор, пока существует ряд, its rowid does not change. Rowid изменится только в особых случаях (таблица rebuild, таблица разделов с включенным перемещением строки, индексированная таблица с обновлением на pk). В таблицах кучи обновление не приведет к изменению параметра rowid, даже если строка перенесена (поскольку она больше не вписывается в блок).

В любом случае rowid является частью метаданных строки и будет сохраняться согласованным в течение всего периода выполнения запроса с тем же consistency mechanism, который сохраняет согласованность столбцов (согласованность чтения во множестве ...).

Кроме того, безопасно использовать встроенные дополнительные запросы, если вы заблокируете строку для обновления (так же, как и первичный ключ). Доступ к строкам с помощью rowid также быстрее, чем поиск первичного ключа (так как поиск первичного ключа - это сканирование индексов + доступ к базе данных).

источник

2013-09-04 15:53:00

Я считаю, что это нормально, если использовать rowid, но мне это не нравится. У вас есть первичный ключ для этой цели, пожалуйста, используйте это. Я считаю, что Oracle в настоящее время гарантирует, что rowid не изменится во время выполнения запроса, но это плохая практика. Например, если он отлично работает, кто гарантирует, что это будет отлично работать на новой версии Oracle при переносе базы данных?

источник

2013-09-04 16:26:15

Если вы считаете, что под капотом Oracle сам использует ROWID для обработки запроса (подумайте «ТАБЛИЦА ДОСТУПА ПО ROWID» в плане выполнения), вам лучше поверить, что ROWID будут надежными в течение всего периода запроса. (Я также придерживаюсь предпосылки, что читатели не блокируют писателей, поэтому Oracle не будет делать какой-либо специальной блокировки, поскольку она обрабатывает записи.)

Если это был случай записи ROWID для использования в последующем SQL поэтому я бы немного насторожился, но для автономного запроса я бы сказал, что все будет в порядке.

источник

2013-09-04 17:03:51

безопасно выполнять select by rowid

ответ

Смежные вопросы