|
Select Sum(STROKA) - новый подход
|
|||
---|---|---|---|
#18+
Есть таблица типа Table1 (id (int), group_id (int), stroka (varchar)) нужно получить таблицу group_id, stroka+stroka+stroka... Классический вариант решения этой задачи я знаю Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Но UDF на больших объемах тормозит. Хочу предложить альтернативный вариант. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.
ИМХО, при большом числе группировок (неуникальных значений в group_id) данный вариант будет работать быстрее. Быстродействие возрастает за счет того, что в данном варианте исходная таблица Table1 сканируется не более 4 раз, тогда как в классическом варианте 1+колич. вызовов UDF = колич. уник. знач. в group_id. С другой стороны, конечно, создание временной таблицы, ее update тоже займет не мало времени. Хотелось бы услышать мнение общественности на этот счет. С уважением ко всем. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2004, 18:55 |
|
Select Sum(STROKA) - новый подход
|
|||
---|---|---|---|
#18+
я чё-то не могу уловить тайного смысла этого: @id=case when @id=group_id then @id else group_id end а вобще - нет никаких гарантий что апдейтится будет всегда в нужном порядке. Насколько было б лучше если б у апдейта был order by... ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2004, 19:51 |
|
Select Sum(STROKA) - новый подход
|
|||
---|---|---|---|
#18+
Да, вообще-то в @id=case .... я в холостую стреляю, можно просто @id=group_id >> нет никаких гарантий что апдейтится будет всегда в нужном порядке Select ... into #tmptbl1 From table1 order by group_id Почему бы после этого update должен обрабатывать в другом порядке? ( Говорят, M$ сформировал отдел разработки MSSQL2k в основном из бывших разработчиков VFP, вот они там везде Scan... EndScan и понавставляли. :) ) ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2004, 16:25 |
|
Select Sum(STROKA) - новый подход
|
|||
---|---|---|---|
#18+
авторSelect ... into #tmptbl1 From table1 order by group_id А проверял? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2004, 16:31 |
|
Select Sum(STROKA) - новый подход
|
|||
---|---|---|---|
#18+
2 andrew_Pr Select ... into #tmptbl1 From table1 order by group_id Почему бы после этого update должен обрабатывать в другом порядке? А почему в том же? Говорят, M$ сформировал отдел разработки MSSQL2k в основном из бывших разработчиков VFP, вот они там везде Scan... EndScan и понавставляли а мне почему-то кажется что они таких залепух как @id=case when @id=group_id then @id else group_id end не пишут и еще, забыл дописать в прошлый раз чем мне не нравится Ваш подход: он ориентируется именно на порядок записей , а не на обработку данных и еще чуть-чуть: если Вы пишите хотите конструктивного обсуждения, то пишите MS , если Вам хочется выразить свои эмоции - то M$ ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2004, 17:06 |
|
Select Sum(STROKA) - новый подход
|
|||
---|---|---|---|
#18+
>> А проверял? Проверять-то проверял, результат всегда правильный. Другое дело, что это действительно не документированная возможность, а значит результаты теста не дают гарантии на будущее. А на счет программистов MS я пошутил. Если кого задел, прошу прощения. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2004, 19:12 |
|
Select Sum(STROKA) - новый подход
|
|||
---|---|---|---|
#18+
>SergSuper >...нет никаких гарантий что апдейтится будет всегда в нужном порядке... На самом деле порядок UPDATE вполне можно указать, если существует соответствующий индекс. Ключевая фраза - UPDATE t FROM table1 t WITH (INDEX()) Проверено на нарастающих итогах, пока сбоев не наблюдалось ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2004, 05:48 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1803638]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
58ms |
get topic data: |
13ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 268ms |
total: | 440ms |
0 / 0 |