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

[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

[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-интерфейсов.