Граждане администраторы баз данных!

[dil]

Помогите, не дайте умереть в неведении!

Как на ANSI SQL (или на Informix-диалекте) пишется _эффективный_ запрос на апдейт многих полей в одной таблице данными из другой таблицы?

Так работает, но по-моему, это сильно неэффективный метод:

UPDATE t1 SET
c1 = (SELECT c1 FROM t2 WHERE t2.id=t1.id),
c2 = (SELECT c2 FROM t2 WHERE t2.id=t1.id),
c3 = (SELECT c3 FROM t2 WHERE t2.id=t1.id),
...
WHERE id IN (SELECT id FROM t2);

Когда поле одно, это ещё ничего, а когда их десяток, это как-то некрасиво выглядит.

Upd: на информиксовском диалекте это пишется так:
UPDATE t1 SET (c1,c2,c3)=
((SELECT c1,c2,c3 FROM t2 WHERE t2.id=t1.id))

Двойные скобки у вложенного селекта существены.

Оригинал этой записи в личном блоге.

Comments

[blacklion.livejournal.com]

TIME WARP! OH, SHI…

А может оно просто верит заголовку-опции timestamp?

[dil.livejournal.com]

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

[blacklion.livejournal.com]

я тоже был в этом уверен. ВНЕЗАПНО ntpdate?

[ivlad.livejournal.com]

Близлежащий ко мне линукс никаких IP таймстампов в icmp-пакетах не ставит.

Ethernet II, Src: Giga-Byt_21:b1:1a (00:14:85:21:b1:1a), Dst: Cisco_9f:2c:40 (00:11:5c:9f:2c:40)
Destination: Cisco_9f:2c:40 (00:11:5c:9f:2c:40)
Address: Cisco_9f:2c:40 (00:11:5c:9f:2c:40)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Giga-Byt_21:b1:1a (00:14:85:21:b1:1a)
Address: Giga-Byt_21:b1:1a (00:14:85:21:b1:1a)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 89.108.74.58 (89.108.74.58), Dst: 89.108.83.67 (89.108.83.67)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 84
Identification: 0x9b25 (39717)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: ICMP (0x01)
Header checksum: 0x8f2e [correct]
[Good: True]
[Bad : False]
Source: 89.108.74.58 (89.108.74.58)
Destination: 89.108.83.67 (89.108.83.67)
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0 ()
Checksum: 0x5f1b [correct]
Identifier: 0x9b71
Sequence number: 28 (0x001c)
Data (56 bytes)

0000 e2 a6 9b 4a 9a 62 02 00 08 09 0a 0b 0c 0d 0e 0f ...J.b..........
0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................
0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()*+,-./
0030 30 31 32 33 34 35 36 37 01234567
Data: E2A69B4A9A62020008090A0B0C0D0E0F1011121314151617...

Да и вообще, не припомню, где они бы в реальной жизни применялись.

[blacklion.livejournal.com]

вот и мне странно всё это

[ivlad.livejournal.com]

Между строчкой 6 и 7 у тебя линк Франкфурт-Москва. Что тебя смутило? Нагруженность внешних каналов РТКома?

10 строчка меня тож удивила.

[dil.livejournal.com]

до такой степени нагруженность, что у меня сайты ощутимо тормозят при загрузке?

[ivlad.livejournal.com]

хз. у меня имя frt-bgw0-ae0-2.rt-comm.ru вообще не резолвится

[dil.livejournal.com]

у меня тоже.

# host 80.81.194.15
15.194.81.80.in-addr.arpa domain name pointer frt-bgw0-ae0-2.rt-comm.ru.
# host frt-bgw0-ae0-2.rt-comm.ru.
Host frt-bgw0-ae0-2.rt-comm.ru. not found: 3(NXDOMAIN)

Магистральный провайдер, чо..

[ivlad.livejournal.com]

А еще в этой стране очень странный пиринг. От меня до франкфуртского:

7 frt-bgw0-ae0-2.rt-comm.ru (80.81.194.15) [AS6695] 88.234 ms 88.286 ms 88.316 ms

а до московского

11 msk-dsr1-ae0-804.rt-comm.ru (217.106.7.218) [AS33934/AS8342] 158.264 ms 158.249 ms 158.237 ms

[dil.livejournal.com]

в какой этой стране? ты ж из американской сети, небось, смотришь?

[ivlad.livejournal.com]

Нет, это мой дедик, стоит в Москве, в Курчатнике, кажется.

traceroute to 217.106.7.218 (217.106.7.218), 30 hops max, 40 byte packets
1 c3750-gw.agava.net (89.108.64.1) [AS39561] 0.423 ms 0.834 ms 1.010 ms
2 skymedia-po-gw.netflow.ru (88.212.194.49) [AS39134] 0.334 ms 0.405 ms 0.481 ms
3 msk46.msk151.transtelecom.net (217.150.45.186) [AS20485] 2.113 ms 2.131 ms 2.155 ms
4 transtele-gw.lnt.cw.net (166.63.222.66) [AS1273] 146.527 ms * 146.527 ms
5 ge-3-2-0-zcr2.lnt.cw.net (166.63.222.65) [AS1273] 79.381 ms 79.385 ms 79.415 ms
6 rtcomm-gw.lnt.cw.net (166.63.211.38) [AS1273] 67.827 ms 67.823 ms 68.502 ms
7 msk-bbn2-ge5-1-0-0.rt-comm.ru (217.106.0.153) [AS33934/AS8342] 118.148 ms 118.176 ms 118.213 ms
8 msk-scr1-tg3-1.rt-comm.ru (217.106.7.242) [AS33934/AS8342] 114.125 ms 114.550 ms msk-scr0-tg4-2.rt-comm.ru (217.106.6.157) [AS33934/AS8342] 114.578 ms
9 msk-scr2-tg1-1.rt-comm.ru (217.106.0.6) [AS33934/AS8342] 114.986 ms msk-scr2-tg1-3.rt-comm.ru (217.106.7.194) [AS33934/AS8342] 115.167 ms msk-scr2-tg1-1.rt-comm.ru (217.106.0.6) [AS33934/AS8342] 115.065 ms
10 217.106.1.146 (217.106.1.146) [AS33934/AS8342] 117.306 ms 117.379 ms 117.396 ms
11 msk-dsr1-ae0-804.rt-comm.ru (217.106.7.218) [AS33934/AS8342] 158.264 ms 158.249 ms 158.237 ms

[visir.livejournal.com]

Это стандартная практика - интерфейсные имена прописываются только в обратной зоне, все так делают.

[dil.livejournal.com]

за это надо больно бить и заставлять читать RFC 1034/1035 до просветления

[visir.livejournal.com]

Ха-ха. Для начала можете попытаться убедить в необходимости еще и прямых записей меня -- не думаю, что у вас это получится :-)

На мой взгляд обратные DNS-записи для интерфейсных адресов нужны исключительно для ускорения работы NOC-а оператора (и только его - забитые туда circuit id и имена интерфейсов клиентам мало чем помогут, разве что название страны или города им будет полезно). А в прямой зоне, для обращения к железкам, достаточно loopback-интерфейсов.

[pondohva-loiso.livejournal.com]

рткомм в последнее время такой рткомм.
Больно часто падают. В итоге у нас шквал звонков.

РТКомм

[visir.livejournal.com]

Народ не готов доплачивать за качество...

Re: РТКомм

[dil.livejournal.com]

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

Re: РТКомм

[visir.livejournal.com]

Не Вы, петерхост.

Re: РТКомм

[dil.livejournal.com]

кому? :)

Re: РТКомм

[tejblum.livejournal.com]

Вероятно, ТТК ;-)) Кому же еще?

Re: РТКомм

[visir.livejournal.com]

тоже вариант )
Но я не уверен, что у них трафик из франкфурта в питер идет не через москву...

Re: РТКомм

[dil.livejournal.com]

да пофигу, как он идет, лишь бы не тормозил :)

[schors.livejournal.com]

ВТорой день лежит.

[dil.livejournal.com]

кто лежит? я сайт-то в общем вижу, только очень медленно

[schors.livejournal.com]

Франкфуртский дырка. Причём, я по IP 80.93.59 так вижу - это москва. Питер тоже. В Питер в петерстар тоже входит трафик через ту дырку.