Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
ASA9.0.2 С точки зрения произовдительности, как лучше делать: Код: plaintext 1. 2. 3. 4. 5. 6. или Код: plaintext 1. 2. 3. 4. 5. Даже не так, "не как лучше делать", а будет ли первый вариант тормознее второго? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 19:19 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
iLLerASA9.0.2 С точки зрения произовдительности, как лучше делать: Код: plaintext 1. 2. 3. 4. 5. 6. или Код: plaintext 1. 2. 3. 4. 5. Даже не так, "не как лучше делать", а будет ли первый вариант тормознее второго? в первом варианте если запис есть тогда сервер ехесуте 2 запроса если нету тогда 1 запрос... а во втором сервер сервер ехесуте 1 запрос если апдейт не прошел успешно тогда добавит новый запис.... суди сам... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 21:02 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
iLLer пишет: > С точки зрения произовдительности, как лучше делать: Раз этот вопрос задается, значит он критичен. Если критичен, то в нужных тебе условиях можно просто запустить оба варианта и сравнить. Если лень - значит не критично. Еще вариант: update t1 set data=data+var2 where pk=var; insert into t1 ON EXISTING SKIP values(var,var2); Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 22:37 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
По идее INSERT ON EXISTING UPDATE как раз и сделан для таких случаев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 23:00 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Раз этот вопрос задается, значит он критичен. Если критичен, то в нужных тебе условиях можно просто запустить оба варианта и сравнить. Если лень - значит не критично. )))) И как же есть на самом деле? Критично или нет? А если серьезно, то экспериментировать в данное время достаточно сложно и долго, ибо собрать макет и воспроизвести рабочую нагрузку в течение длительного времени ради одного пунктика не вижу особого смысла. Проще спросить людей, вдруг кто-то уже проверял данный момент. Если у кого-то возникнет какой-то спорный вопрос, который я проверял, я обязательно поделюсь своим опытом. На то тут и форум... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 23:01 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
ASCRUSПо идее INSERT ON EXISTING UPDATE как раз и сделан для таких случаев. Вся проблема в этом: update t1 set data= data+var2 where pk=var; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2005, 23:02 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
iLLer ASCRUSПо идее INSERT ON EXISTING UPDATE как раз и сделан для таких случаев. Вся проблема в этом: update t1 set data= data+var2 where pk=var; Не вижу здесь проблемы: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 14:08 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
ASCRUS пишет: > Не вижу здесь проблемы: > > insert into t1 (pk, data) on existing update > select var, var2 + IsNull(t1.data, 0) > from dummy > left join t1 on t1.pk = var; В FAQ сей шедевр. Я не додумался до такого ;) Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 15:42 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
SQL может все, если правильно готовить :) Я уже давно от циклов отошел, как только RowGenerator появилась в ASA - удобно и вкусно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 16:44 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
Второе. На одно чтение меньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2005, 22:32 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
Да, такой финт с джойном я и сам придумал)) И наткнулся на такой глюк, что lateral с dummy работает не как outer а как inner!!! Т.е. вот это: select * from (select 1000) as v(k),lateral(select data from aaa where id=k) as vv(g) выдает пустой набор, если в таблице aaa нет записи, у которой id=1000. С dummy та же бодяга. А должен выдать по-любому хотя бы одну запись! Posted via ActualForum NNTP Server 1.3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 00:54 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
Lateral тут не виноват. Даже если его убрать получишь тоже самое. Похоже на глюк с dummy таблицей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 01:27 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
iLLer Да, такой финт с джойном я и сам придумал)) И наткнулся на такой глюк, что lateral с dummy работает не как outer а как inner!!! Т.е. вот это: select * from (select 1000) as v(k),lateral(select data from aaa where id=k) as vv(g) выдает пустой набор, если в таблице aaa нет записи, у которой id=1000. С dummy та же бодяга. А должен выдать по-любому хотя бы одну запись! Posted via ActualForum NNTP Server 1.3 А зачем LATERAL, когда через LEFT JOIN в моем примере все замечательно работает ? P.S. Кстати LATERAL не только с Dummy работает как INNER JOIN, но и с обычными таблицами. Только не понятно - это правильное его поведение или баг. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 07:13 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
Кстати, производительность EXISTS здесь ни при чем. Я предлагаю переименовать топик в "проверять ли наличие записи перед ее UPDATE". Но я не знаю, как это делать, если честно, и хотел посоветоваться с вами (о целесообразности переименования). Да, кстати еще о теме -- хотел отметить, что это -- один из стандартных трюков или финтов, которые предлагается делать во всех рекомендациях по повышению производительности, причем для всех серверов, поскольку тут особенно ничего специфичного для конкретной СУБД нет. Т.е. рекомендуется не проверять, а попытаться сделать UPDATE, и если он не нашел записи, сделать INSERT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 09:51 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
ASCRUSКстати LATERAL не только с Dummy работает как INNER JOIN, но и с обычными таблицами. Только не понятно - это правильное его поведение или баг. А у меня с таблицами работает как outer, только с dummy(или его пустым аналогом) глючит. Да и в доках написано, что внешнее соединение это. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 16:42 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
iLLer ASCRUSКстати LATERAL не только с Dummy работает как INNER JOIN, но и с обычными таблицами. Только не понятно - это правильное его поведение или баг. А у меня с таблицами работает как outer, только с dummy(или его пустым аналогом) глючит. Да и в доках написано, что внешнее соединение это. Код: plaintext 1. 2. 3. 4. 5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 17:07 |
|
||
|
проверять ли наличие записи перед ее UPDATE
|
|||
|---|---|---|---|
|
#18+
ASCRUSБилд 3198. Вот, а у меня 3182)))) Видимо они что-то зацепили. Кстати, в этом же билде у меня бэкап подвисал. Выяснилось, что поскольку бэкап у меня идет 40 минут(база 40 гиг), то при наложении checkpointa на backup с указанными wait'ами в бэкапе они держат друг-друга неопределенное время. А второй системный коннект с номером за 1000000000 как раз и есть checkpoint. Не в тему, но зато про этот билд) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2005, 18:45 |
|
||
|
|

start [/forum/topic.php?fid=55&fpage=95&tid=2013317]: |
0ms |
get settings: |
9ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 253ms |
| total: | 359ms |

| 0 / 0 |
