SQL, выбор и обновление - PullRequest
       11

SQL, выбор и обновление

1 голос
/ 04 января 2009

Я пытаюсь выбрать 100 строк в базе данных, которая содержит 100000 строк, и обновить эти строки после.

проблема в том, что я не хочу дважды заходить в БД для этой цели, так как обновление помечает только эти строки как "прочитанные".

Есть ли способ сделать это в Java, используя простые библиотеки JDBC? (надеюсь, без использования хранимых процедур)

обновление: хорошо, вот некоторые уточнения.

есть несколько экземпляров одного и того же приложения, работающего на разных серверах, все они должны выбрать 100 строк «UNREAD», отсортированных по столбцу creation_date, прочитать данные BLOB-объекта внутри него, записать их в файл и передать этот файл на некоторый сервер , (Я знаю доисторический, но требования есть требования)

Часть чтения и обновления предназначена для того, чтобы каждый экземпляр получал различный набор данных. (по порядку такие хитрости, как шансы и четности, не сработают: /)

Мы выбираем данные для обновления. данные передаются по проводам (мы ждем и ждем), а затем мы обновляем их как «ЧИТАТЬ». затем отпустите блокировку для чтения. все это занимает слишком много времени. Одновременно читая и обновляя, я хотел бы сократить время блокировки (с момента, когда мы используем select для обновления, до фактического обновления), чтобы при использовании нескольких экземпляров увеличивалось число считываемых строк в секунду.

Еще есть идеи?

Ответы [ 4 ]

2 голосов
/ 04 января 2009

Мне кажется, что здесь может быть несколько способов интерпретации вопроса.

  1. Вы выбираете строки для единственная цель их обновления и не читая их.
  2. Вы выбираете строки для отображения кому-то, и отмечая их как читать по одному или все по группе.
  3. Вы хотите выбрать строки и отметить они как прочитанные в то время, которое вы выбираете их.

Давайте сначала рассмотрим вариант 1, так как он кажется самым простым. Вам не нужно выбирать строки для их обновления, просто выполните обновление с предложением WHERE:

update table_x
set read = 'T'
where date > sysdate-1;

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

В JDBC (Java) есть средство для пакетного обновления, где вы выполняете набор обновлений одновременно. Это хорошо работает, когда мне нужно выполнить много обновлений, которые имеют точно такую ​​же форму.

Вариант 3, где вы хотите выбрать и обновить все в одном кадре. Лично я не вижу в этом особой пользы, но это не значит, что другие этого не делают. Я полагаю, что какая-то хранимая процедура уменьшит количество поездок в оба конца. Я не уверен, с какой БД вы здесь работаете, и не могу предложить конкретику.

1 голос
/ 04 января 2009

Ходить в БД не так уж и плохо. Если вы ничего не возвращаете «по проводам», то обновление не должно нанести вам слишком много урона, а всего несколько сотен тысяч строк. Что тебя беспокоит?

1 голос
/ 04 января 2009

Если вы делаете SELECT в JDBC и перебираете ResultSet для ОБНОВЛЕНИЯ каждой строки, вы делаете это неправильно. Это (n + 1) проблема запроса, которая никогда не будет работать хорошо.

Просто выполните ОБНОВЛЕНИЕ с предложением WHERE, которое определяет, какие из этих строк необходимо обновить. Таким образом, это обход в одну сеть.

Не будь слишком ориентированным на код. Позвольте базе данных выполнить работу, для которой она была разработана.

0 голосов
/ 04 января 2009

Разве вы не можете просто использовать одно и то же соединение, не закрывая его?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...