Форум: "Базы";
Текущий архив: 2007.09.30;
Скачать: [xml.tar.bz2];
Внизкак узнать, добавлена ли запись ? Найти похожие ветки
← →
Parenek (2007-05-18 14:25) [0]есть таблица в которой поле Pole1 индексировано и имеет значение unique, выполняется такая вставка данных:mysql>
INSERT INTO table (Pole1,Pole2) VALUES (value1,value2)
ON DUPLICATE KEY UPDATE pole2=value3;
т.е. по этому добавлению если value1 уже содержится в таблице, то оно не будет добавлено, и pole2 будет изменено на value3 в той строке где найдено pole1 с таким же value1;
если не найдено value1 в таблице пo pole1 то оно будет добавлено.
а как узнать добавлена новая строка или изменена уже имеющаяся... ?
← →
Muzhichok (2007-05-18 14:27) [1]проще явно делать либо insert либо update
← →
Parenek (2007-05-18 14:32) [2]чем мотивируешь?
так проще узнать есть ли такая запись?
и если есть то сделать update нужного поля?
разве так проще?
← →
Muzhichok (2007-05-18 14:46) [3]тем, что так у тебя будет if и else
и в этих ветках ты сможешь "узнать добавлена новая строка или изменена уже имеющаяся"
← →
Parenek (2007-05-18 15:07) [4]не убедил :)
1. ты хочешь делать сначала запрос на поиск нужного значения по нужному полю
2. потом узнаешь нашел сервер или нет (кстати как ты это делаешь?)
3. потом ты делаешь update (по id найденного поля) или вставляешь если не нашел сервер.
так?
← →
Muzhichok (2007-05-18 15:09) [5]ну да, обычно так и делал
← →
Sergey13 © (2007-05-18 15:11) [6]> [4] Parenek (18.05.07 15:07)
Перед своим запросом запроси наличие вставляемого ключа. Из ответа и так будет понятно, что произойдет.
← →
Val © (2007-05-18 15:16) [7]если есть обработчики исключений у этого сервера, то попытаться сделать вставку, обработать исключение, сделать апдейт.
встречный вопрос - а зачем такое знание надобно, если результат действий один?
← →
Muzhichok (2007-05-18 15:18) [8]ежели речь про стандартное добавление/обновление свойств некоей сущности, то чем плоха такая конструкция
if @id = 0
insert into ttt(name, desc) values(@names, @desc)
else
update ttt set name=@name, desc=@desc where id=@id
?
в роли id, я так понял, pole1 и выступает?
← →
Parenek (2007-05-18 15:29) [9]
> Sergey13 © (18.05.07 15:11) [6]
>
> Перед своим запросом запроси наличие вставляемого ключа.
> Из ответа и так будет понятно, что произойдет.
а чем это принципиально отличается от:
> 1. ты хочешь делать сначала запрос на поиск нужного значения
> по нужному полю
> если есть обработчики исключений у этого сервера, то попытаться
> сделать вставку, обработать исключение, сделать апдейт.
> встречный вопрос - а зачем такое знание надобно, если результат
> действий один?
1.обработчик вроде есть, но зачем им пользоваться в данном случае, если сервер корректно обрабатывает поле с уникальным значением
знание чего? если результата что было сделано, то для статистики добавления. (она нужна не просто ради любопытства - она является частью контроля)
← →
Sergey13 © (2007-05-18 15:31) [10]> [9] Parenek (18.05.07 15:29)
> а чем это принципиально отличается от:
Тем, что ты получишь ответ на свой вопрос в сабже.
> а как узнать добавлена новая строка или изменена уже имеющаяся... ?
Даже будешь знать этот ответ раньше, чем произойдет само событие. 8-)
← →
Parenek (2007-05-18 15:35) [11]
> Sergey13 © (18.05.07 15:31) [10]
если честно или я запутался или я еще ламер (скорее второе=))
примерчик можно?
← →
Val © (2007-05-18 15:38) [12]>но зачем им пользоваться в данном случае
чтобы получить решение твоего вопроса.
try
вставка;
накручивание счетчика вставок;
except
if облом с уник.ключом then
апдейт;
else raise;
end;
← →
Sergey13 © (2007-05-18 15:44) [13]> [11] Parenek (18.05.07 15:35)
> примерчик можно?
Select count(Pole1) as kol_vo from table where Pole1=value1;
Если kol_vo>0 заначит запрос
INSERT INTO table (Pole1,Pole2) VALUES (value1,value2)
ON DUPLICATE KEY UPDATE pole2=value3;
проапдейтит запись[и]. Если kol_vo=0 значит вставит.
← →
Sergey13 © (2007-05-18 15:46) [14]> [11] Parenek (18.05.07 15:35)
Кроме того, если value2 и value3 гарантировано раличны, то запрос ПОСЛЕ вставки
Select Pole2 from table where Pole1=value1;
также даст тебе ответ на вопрос.
← →
Muzhichok (2007-05-18 15:53) [15]
> ON DUPLICATE KEY UPDATE
а что кстати даст select last_insert_id() в случае срабатывания этой конструкции?
это если конечно pole1 - autoincrement
← →
Parenek (2007-05-18 15:54) [16]
> Sergey13 © (18.05.07 15:46) [14]
точно, а об это я не подумал..
позор мне начинающему бд криейтеру 8-)
← →
Parenek (2007-05-18 15:56) [17]
> > ON DUPLICATE KEY UPDATE
>
> а что кстати даст select last_insert_id() в случае срабатывания
> этой конструкции?
> это если конечно pole1 - autoincrement
> <Цитата>
еще не знаю :)
pole0 - autoincrement
← →
Anatoly Podgoretsky © (2007-05-18 21:35) [18]> Parenek (18.05.2007 15:07:04) [4]
Между 2 и 3 - запись может пропасть или наоборот появиться.
← →
Parenek (2007-05-21 15:55) [19]
> Anatoly Podgoretsky © (18.05.07 21:35) [18]
согласен, а как корректнее узнать учитывая то, что добавлять данные могут несколько клиентов сразу?
← →
Sergey13 © (2007-05-21 16:00) [20]> [19] Parenek (21.05.07 15:55)
В конце концов, если уж так важно, заведи отдельное служебное поле, куда пиши код текущей операции.
Синтаксис мускула не знаю, но наверное как то так:INSERT INTO table (Pole1,Pole2,flag) VALUES (value1,value2,0)
ON DUPLICATE KEY UPDATE pole2=value3, flag=1;
← →
Parenek (2007-05-21 16:19) [21]и что оно даст, есл выполняется условие то, о котором ты писал..
по-моему это дублирование информации..
> Sergey13 © (18.05.07 15:46) [14]
← →
Sergey13 © (2007-05-21 16:22) [22]> [21] Parenek (21.05.07 16:19)
> и что оно даст
Мне ничего. 8-)
← →
Parenek (2007-05-21 16:25) [23]
> Мне ничего. 8-)
я имею в виду, что то служебное поле никчему из другого поля уже видно изменение так как уже подмечено > Sergey13 © (18.05.07 15:46) [14]
← →
Parenek (2007-05-21 16:28) [24]и это кстати чуть ли не единственный самый простой и самый надежный способ проверки моего сабжа..
по крайней мере другого надежного и простого такого не знаю.. =)
но есть и недостаток - лишний запрос, чтобы узнать..
← →
Sergey13 © (2007-05-21 16:29) [25]> [23] Parenek (21.05.07 16:25)
Я отвечал на
> [19] Parenek (21.05.07 15:55)
Если в момент записи сам запрос заполнит флаговое поле, то в этом случае разночтений из-за многопользовательской работы вроде быть не может. Предыдущие мои советы оставляли лазейку для этого.
← →
ANB © (2007-05-21 18:11) [26]
> Parenek (21.05.07 16:28) [24]
Если синтаксис СУБД позволяет сделать мерж, то все предаврительные проверки проверки - от лукавого. Не слушай никого и делай именно так, как написал.
В оракле можно выцепить результат обработки по псевдопеременным. Раз MySQL предусмотрел такой синтаксис, значит, скорее всего, есть возможность выцепить и у него.
← →
Parenek (2007-05-22 00:46) [27]
> ANB ©
попробую :)
кстати, а что будет делать субд, если одновременно два клиента пробуют запихнуть одно и то же Value1 (напомню: по условию одинаковых быть не должно см. пост №1) и будут ли корректны данные проверки: добавлено или исправлено (проверка в посте №14) ?
← →
Sergey13 © (2007-05-22 08:51) [28]> [27] Parenek (22.05.07 00:46)
> если одновременно два клиента пробуют запихнуть одно и то же Value1
Это утопия. 8-)
Они по любому встанут в очередь.
← →
Parenek (2007-05-22 20:22) [29]ну я про очередь знаю, вот про проверку на добавление - может ли получиться ситуация:
пытаюсь добавлять запись - она уникальна и сервер ее добавляет, я делаю запрос на проверку, чтобы это выяснить (проверяю как в 14 посте), но запросы следуют друг за другом, и между моими запросам на добавление и считывание (проверку), может быть произведен запрос на добавление другим клиентом?
← →
ANB © (2007-05-23 12:01) [30]
> и между моими запросам на добавление и считывание (проверку),
> может быть произведен запрос на добавление другим клиентом?
>
Да. Если специально не принять мер по блокировкам.
← →
Mysql (2007-05-23 16:48) [31]
> Да. Если специально не принять мер по блокировкам.
встречный вопрос - как блокировать?
и соответственно снимать блокировку :)
← →
ANB © (2007-05-23 17:08) [32]
> встречный вопрос - как блокировать?
> и соответственно снимать блокировку :)
MySQL - не мой конек. Ищи в доке или жди спецов по оному. Сходи на SQL.RU в спец.форум MySQL. Однако, ИМХО - блокировать таблицу только для того, чтобы узнать результат предыдущего DML - не лучшая идея.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2007.09.30;
Скачать: [xml.tar.bz2];
Память: 0.53 MB
Время: 0.053 c