|
|
|
Оптимизация запроса.
|
|||
|---|---|---|---|
|
#18+
Дан файл DAN.DBF Код: plaintext 1. 2. 3. со сведениями о годовых доходах сотрудников предприятия с учетом их принадлежности определенным отделам. Составить программу для формирования справки о сотрудниках, доход которых выше среднего по каждому отделу (для мужчин и женщин в отдельности) Мой неработающий вариант. Помогите доработать и если нетрудно, поясните вкратце: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2007, 00:33 |
|
||
|
Оптимизация запроса.
|
|||
|---|---|---|---|
|
#18+
w2000Дан файл DAN.DBF Код: plaintext 1. 2. 3. со сведениями о годовых доходах сотрудников предприятия с учетом их принадлежности определенным отделам. Составить программу для формирования справки о сотрудниках, доход которых выше среднего по каждому отделу (для мужчин и женщин в отдельности) Мой неработающий вариант. Помогите доработать и если нетрудно, поясните вкратце: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. я бы сделал так (должен работать на 100 %): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. или так (тоже должен работать, но, скорее всего , медленнее предыдущего варианта): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. или так (только для VFP, должен работать аналогично первому варианту, но надо проверять...): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2007, 08:30 |
|
||
|
Оптимизация запроса.
|
|||
|---|---|---|---|
|
#18+
Станислав С , спасибо огромное!!! P.S. Почему, по вашему мнению, вариант (2) с вложенным подзапросом будет работать медленнее, нежели вариант (1) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2007, 10:42 |
|
||
|
Оптимизация запроса.
|
|||
|---|---|---|---|
|
#18+
w2000 Станислав С , спасибо огромное!!! P.S. Почему, по вашему мнению, вариант (2) с вложенным подзапросом будет работать медленнее, нежели вариант (1) ? Причина следующая. При работе первого варианта будет создана временная таблица (temp1), в которую поместятся результаты промежуточных расчетов среднего значения, а уже затем будут построены связи для отбора необходимых значений (A.KOD_OTDEL=b.KOD_OTDEL). При работе второго варианта для каждой записи первой таблицы надо будет подсчитать среднее значение, даже если оно уже было посчитано 2-3 записи назад (A.DOHOD > (SELECT AVG(B.DOHOD) FROM DAN B WHERE A.KOD_OTDEL=b.KOD_OTDEL )). В целом это более накладный вариант, хотя могут сработать оптимизаторы, хеши и т.д., ускоряющие работу. Конечно, если у Вас от 0 до 10 - 100 записей, то заметить замедление, возможно, не удастся. Но, скажем, на 500 000 записей замедление уже проявится... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2007, 11:03 |
|
||
|
Оптимизация запроса.
|
|||
|---|---|---|---|
|
#18+
Но с другой стороны-то, временная таблица требует больших затрат памяти, если имеется большое кол-во записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2007, 12:40 |
|
||
|
Оптимизация запроса.
|
|||
|---|---|---|---|
|
#18+
w2000Но с другой стороны-то, временная таблица требует больших затрат памяти, если имеется большое кол-во записей. Во-первых, не настолько больших (количество отделов, по которым производится группировка, является конечным числом) - мы ведь храним только подсчитанные итоги Во-вторых, повторное вычисление одних и тех же (уже расчитанных ранее) значений более медленное "занятие", чем поиск в готовом массиве/таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.04.2007, 13:07 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=34447162&tid=1589575]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
75ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 387ms |

| 0 / 0 |
