Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Ёжик25 Member Откуда: оттуда Сообщений: 360 |
Drop table #src; drop table #trg create table #src (id int, type int, value nvarchar(20)) insert into #src values (10,8,'888'), (10,8,'777'), (10,8,'999'), (111,8,'999') create table #trg (id int, type int, value nvarchar(20)) insert into #trg values (10,8,'111') select #src.value from #trg join #src on #trg.id = #src.id and #trg.type=#src.type --возвращает 3 строки (как и в таблице источнике) со значениями '888','777','999' по полю value update #trg set #trg.value = #src.value from #trg join #src on #trg.id = #src.id and #trg.type=#src.type --обновление в таблице #trg произошло только по "первому" значению '888' Почему такая конструкция работает и не вызывает ошибки? Ведь по условию возвращается 3 значения. Но SQL выбирает "первое". Слово "первое" в кавычках, потому что, как я понимаю, для реляционной таблицы понятия первой записи не имеет смысла. Dопрос в том, по какому принципу происходит выборка одного значения, по которому происходит обновление поля value в таблице #trg. Как мне в коде выше узнать, на какое значение обновляется #trg.value. |
15 май 19, 14:56 [21885374] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
Ёжик25, с чего вы решили что обновляет "первое"? оставляет "последнее" |
15 май 19, 15:01 [21885381] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47051 |
|
||
15 май 19, 15:11 [21885392] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8723 |
А есть какой-то пруф? Просто, как я помню, не "первое" или "последнее" а просто "одно из". |
||
15 май 19, 15:12 [21885394] Ответить | Цитировать Сообщить модератору |
Ёжик25 Member Откуда: оттуда Сообщений: 360 |
iap, что то ничего не нашел, прошу, дайте ссыль, весь интернет уже облазил на эту тему. |
15 май 19, 15:18 [21885400] Ответить | Цитировать Сообщить модератору |
Ёжик25 Member Откуда: оттуда Сообщений: 360 |
TaPaK, выполните приведенный скрипт и посмотрите результат) |
15 май 19, 15:18 [21885403] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
оно так и будет, предварительно результат не определён, вопрос как будет отсортировано/пересортировано в плане
нет спасибо |
||||||||
15 май 19, 15:20 [21885406] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8723 |
Это я и сам видел, я хотел увидеть какой-то пруф на "последний" с учетом "сортировки" в плане. |
||||||
15 май 19, 15:23 [21885408] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
расшифровуйте |
||||||
15 май 19, 15:24 [21885410] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8723 |
хмм, это откуда? В справке по update такого нет, поиск в гуле находит только про stream aggregate. |
||||
15 май 19, 15:31 [21885422] Ответить | Цитировать Сообщить модератору |
Ёжик25 Member Откуда: оттуда Сообщений: 360 |
как я понял, из за такой "недетерминированности" мы не можем абсолютно точно сказать, каким значением из нескольких будет обновлена запись, и следует в таком случае вводить дополнительную логику, row_count какой нибудь, или времянку с отсортированными значениями из таблицы-источника? |
||||
15 май 19, 15:31 [21885423] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
это тот оператор которое "это" делает. На самом деле вопрос бессмысленный, правильней ответ "не определён" заранее |
||||
15 май 19, 15:32 [21885426] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8723 |
из-за такой недетерменированности, лучше вообще избегать подобных апдейтов. |
||||
15 май 19, 15:32 [21885427] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
пусть sql угадывает какое же значение ты хотел получить |
||||
15 май 19, 15:33 [21885429] Ответить | Цитировать Сообщить модератору |
Ёжик25 Member Откуда: оттуда Сообщений: 360 |
Вообще все началось с того, что я пытаюсь из SQL в Postgresql засунуть логику MERGE, которая, кстати, ругается на несколько результирующих значений и не работает. Пока только через вот такую конструкцию получилось: WITH cte ( update target from source ...returning ...)insert ...select ...from source left join cte on ...where cte ... is null ну и вот столкнулся с такой "недетерминированностью" операции UPDATE. Что ж, придется вводить таки дополнительную логику. Всех благодарю. Вопрос закрыт. |
||||
15 май 19, 15:39 [21885435] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8723 |
"это" вполне может делать и hash aggregate |
||
15 май 19, 15:41 [21885438] Ответить | Цитировать Сообщить модератору |
Akina Member Откуда: Зеленоград, Москва, Россия Сообщений: 20970 |
MS как-то не любит распространяться о внутренней кухне, предпочитая просто рассказать про недетерминированность. В доке к MySQL, например, чётко написано - любая запись обновляется только один раз за запрос. Отсюда и "первой записью" - остальные попытки обновления этой же записи игнорятся, ибо "уже было". А уж какая реально будет "первая" - это фиг знает, бо сортировки в подзапросах (без TOP N) тупо игнорятся (а местами так и вовсе запрещены, вроде). |
||
15 май 19, 15:43 [21885444] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
а делает stream aпgregate... или вы предлагаете на этапе join выбрасывать всё? |
||||
15 май 19, 15:43 [21885445] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47051 |
SELECT @Var=FieldValue FROM TableName С UPDATE это не связано. Про UPDATE написано следующее:
|
||||
15 май 19, 15:47 [21885449] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8723 |
Еще раз, "это" не обязательно делает stream aggregate, "это" может делаться и SQL сервером и через Hash aggregate с aggrtype any |
||||
15 май 19, 15:50 [21885453] Ответить | Цитировать Сообщить модератору |
Ёжик25 Member Откуда: оттуда Сообщений: 360 |
iap, вообще, конечно, я был очень удивлен такому поведению. Следовало бы, на мой взгляд, возвращать ошибку обновления, как это делается при MERGE. Ну давайте с тем же успехом переменной присваивать "первое" значение из множественного набора результата SELECT. Чего уж там!)))) |
15 май 19, 15:53 [21885459] Ответить | Цитировать Сообщить модератору |
msLex Member Откуда: Сообщений: 8723 |
Поведение странное, но оно задокументировано, что автомат превращает его (поведение) в фичу. |
||
15 май 19, 15:55 [21885462] Ответить | Цитировать Сообщить модератору |
Посетитель Member Откуда: Сообщений: 1210 |
напишите свой SQL Server и управляйте его поведением как пожелаете. зачем удивляться тому, что поведение соответствует описанию в документации? |
||
15 май 19, 15:57 [21885466] Ответить | Цитировать Сообщить модератору |
iap Member Откуда: Москва Сообщений: 47051 |
Правда, UPDATE появился на 200 лет раньше ![]() Таких моментов много. Например, во многих случаях необязательно строго придерживаться заявленного стиля даты в функции CONVERT() - сервер сконвертирует даже приблизительно похожую на дату строку. Разве не безобразие? Строгости к нам, балбесам, не хватает! |
||
15 май 19, 16:08 [21885485] Ответить | Цитировать Сообщить модератору |
TaPaK Member Откуда: Kiev Сообщений: 6801 |
вперёд в спортлото https://feedback.azure.com/forums/908035-sql-server |
||
15 май 19, 16:08 [21885487] Ответить | Цитировать Сообщить модератору |
Топик располагается на нескольких страницах: [1] 2 вперед Ctrl→ все |
Все форумы / Microsoft SQL Server | ![]() |