Ключ последней обновленной записи

[masterdela]

Доброго времени суток!

Есть необходимость получить ключ последнее измененной записи с помощью UPDATE. А точнее сначала обновить запись, потом ее выбрать. Очень важна точность и скорость, т.к. с таблицей одновременно работают 20 человек, в таблице 100 тыс. записей.

Не нашел встроенного решения, потому на данный момент думаю в сторону следующей структуры:

r = генерим случайное число;

UPDATE TOP 1 Table SET Field1 = r
SELECT * FROM Table WHERE Field1 = r

[Serge_Bliznykov]

А какая СУБД?

[soleil@mmc]

вот сижу 2й день и пытаюсь понять - что же на самом деле хотел ТС?
если запись меняли, то у нее есть ключевое поле, по которому ее подтягивали для изменений, иначе поменяют не одну конкретную запись, а несколько или вообще все
если нужны записи, которые поменял кто-то и совсем недавно, то в субд есть временные штампы - нужно под это дело завести отдельную колонку в табличке, например, date_modified date и туда на триггере при апдейте писать sysdate (или что там предусмотрено вашей субд - дату и время в одном поле) и плюс к этому еще и писать юзера, внесшего изменения (опять же многие субд имеют эти сведения)

[masterdela]

Serge_Bliznykov
Мои извинения, сервер MS SQL 2000.

soleil@mmc
Сегодня как раз думал о том, чтобы при update в доп. поле вписывать уникальный ID, составленный из дата-время-юзер. Только не user БД, а id, под которым зашли на веб-интерфейс. Думая трезво, понимаю, что это самый точный и надеженый способ из мне известных, но самый ли быстрый...

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

Для этого есть UPDATE TOP (1) Table. Потому ключ неизвестен.

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

RecordSet = SELECT * FROM Table WHERE Status=0
UPDATE Table SET Status=1 WHERE id = RecordSet("id").Value

Так все работало без проблем. Но когда появился случай, когда одновременно работают 20 человек с таблицей со 100 тыс. записей, получается, что за промежуток между SELECT и UPDATE успевает сработать выборка от другого юзера и выбирается эта же строка, которую уже выбрал предыдущий пользователь, но интерфейс не успел ее "заблокировать" ... Вот так получается, что одна и та же строка попадает нескольким юзерам.

Потому, пока не вижу другого выхода, как сначала унифицировать и заблочить запись, а потом выбрать ее для работы. Есть ли другое решение ?

[masterdela]

Упс. Теоретически где-то читал про конструкцию вида

UPDATE TOP (1) Table Set Status=1

Практически оказалось, что такого нет в MS SQL 2000, а только начиная с 2005. А поиск лишь дал тоже самое, что у меня и сейчас есть, только одним запросом:

UPDATE Table SET Status=1 WHERE ID IN (SELECT TOP 1 ID FROM Table WHERE Status=0)

Насколько такой подход лучше покажут тесты.

[soleil@mmc]

кто о чем, а вшивый о бане...
сначала ответьте на вопрос "зачем это все нужно?"
я не изучал механизма блокировок/защелок на мсскуэле, но есть подозрение что все несколько проще чем тут приведено
нужно лочить записи при редактировании?
ну и делай при попытке открыть запись на редактирование так:
1) попытка залочить запись
update table set lock_user = user where id = ... and lock_user is null
2) далее проверка кем реально залочена запись
select lock_user from table where id = ...

и дальше если это текущий юзер, то разрешать редактировать, если нет, то бай-бай
и не забыть разлочить запись после редактирования

[masterdela]

soleil@mmc
Я вроде бы максимально описал, что мне нужно (2 поста выше). Вы совсем о другом мне говорите. Под "заблочить" я имею ввиду изменить поле Status=1, по которому она была выбрана, чтобы под следующую выборку SELECT TOP 1 * FROM Table WHERE Status=0 она не попала.

[soleil@mmc]

Цитата:
если запись меняли, то у нее есть ключевое поле, по которому ее подтягивали для изменений, иначе поменяют не одну конкретную запись, а несколько или вообще все

Для этого есть UPDATE TOP (1) Table. Потому ключ неизвестен.

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