Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 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.52 MB
Время: 0.042 c
2-1188901427
Adventure
2007-09-04 14:23
2007.09.30
Опять про кодовые страницы в Paradox через DBE


15-1188538117
Kolan
2007-08-31 09:28
2007.09.30
Поиск в выподающем списке, покритекуйте идею.


15-1188909994
Denis_
2007-09-04 16:46
2007.09.30
Палец заменит кредитку?


15-1188056939
Riply
2007-08-25 19:48
2007.09.30
Вымогательство на дорогах.


4-1175497718
valager
2007-04-02 11:08
2007.09.30
Чтение данных из другого приложения





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский