|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
Привет! Тут такая задача - есть бд тарификации тел. разговоров. В этой бд есть такие поля RowMark i - означает тип пакета abonent c(7) - кто звонил date d - дата звонка time c(5) - время minutes i - минут от полуночи talk_sec i - время разговора abonent2 c(20) - набранный номер Здесь важен RowMark вот в каком смысле. Дело в том, что пакеты, используемые для тарификации официально имеют значение 42316, но они так же дублируются еще какимто технологическим пакетом со значением уже 42317, который обычно создается следом за пакетом 42316. Проблема в том, что: 1) дублирование какбы "неточное", т.е. в дубль-пакете 42317 может отличаться длительность разговора на +-3 секунды, а так же время начала разговора может быть +1 минута (зависит восновном от случаев когда разговор начат в последние секунды минуты), причем секунды начала разговора не отмечаются нигде и никак, т.е. точность начала разговора есть до минуты. 2) иногда в бд попадают только дубль-пакеты с меткой 42317, а их "родителя" 42316 при этом может не быть и наоборот. Задача. Отбросить дубль-пакеты с меткой 42317, если в наличии есть оригинал с меткой 42316, учитывая неполное и неидеальное сходство. При этом должны остаться записи с меткой 42316 непродублированные с меткой 42317 и наоборот. Я сделал следующим образом. В отдельную бд (dbf_42316) выбираю только записи с меткой 42316, т.к. их обычно меньше, а затем по полной базе (dbfTemp) делаю SCAN/LOCATE/DELETE: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Я размышлял над индексацией, но так и не пришел к определенному решению. Непонятно как это можно оптимизировать - может подскажете? спасибо. вфп9 ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 10:47 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
Что связывает пару 42316 и 42317? Ключ какой-то есть или только составной типа кто и когда звонил? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 10:51 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
Ничего не связывает, кроме того что воочию видно что есть дубликат, т.е. ключа нет и единственная возможность это вот такое сравнение. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 11:48 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
Может проиндексировать dbf_42316 по выражению Abonent+dtoc(Date)+Abonent2, а затем в твоем скане вместо Locate использовать seek() по этому выражению и при удачном поиске сделать цикл с построчным перебором всех совпадений на предмет сравнения минут и секунд? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 14:31 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
короче сам оптимизировал, но еще не уверен что все ок, хотя быстрее в разы. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 14:36 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
ОТЭМожет проиндексировать dbf_42316 по выражению Abonent+dtoc(Date)+Abonent2, а затем в твоем скане вместо Locate использовать seek() по этому выражению и при удачном поиске сделать цикл с построчным перебором всех совпадений на предмет сравнения минут и секунд?спасибо, пришел к аналогичному :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 14:38 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
Можно еще ускорить если выполняются следующие предположения: 1. записи идут в хронологическом порядке как для 42316 так и для 42317 2. Запись 42316 всегда перед 42317 примерно так без промежуточной таблицы и индексов: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
Даже если мои предположения 1,2 не верны, то надо индекс по ttoc(dtot(dbfTemp.date) + dbfTemp.minutes * 60, 1) + STR(RowMark, 5) Для еще ускорения можно убрать EOF() (это довольно медленная операция) - запомнить RECNO() последней записи и проверять его внутри DO WHILE. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 15:33 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
Не все поправил. Вместо Код: plaintext
Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
05.08.2008, 15:36 |
|
Возможна ли оптимизация такого кода...
|
|||
---|---|---|---|
#18+
Маленько дам вопросов для размышления. В связи с тем, что: > 1) дублирование какбы "неточное", т.е. в дубль-пакете 42317 может > отличаться длительность разговора на +-3 секунды, а так же время начала > разговора может быть +1 минута (зависит восновном от случаев когда > разговор начат в последние секунды минуты), причем секунды начала > разговора не отмечаются нигде и никак, т.е. точность начала разговора есть > до минуты. Во первых, где гарантия, что отличие именно ДО минуты, а никак не больше (ну скажем пару минут). Во вторых, если звонок идет на границе суток, то и даты могут быть разные. Третье. Я в течении одной минуты совершил два (три) звонка на один и тот же номер. Длительность разговора 5 - 10 секунд. Но звонки были, разговоры тоже. В связи с тем, что: > 2) иногда в бд попадают только дубль-пакеты с меткой 42317, а их > "родителя" 42316 при этом может не быть и наоборот. Ты их можешь посчитать за один разговор и, соответственно, затрешь как дубль. > Задача. А вот задача как раз в том, чтобы сделать нормальный билинг, а не пытаться выудить хоть что-то из имеющегося. Posted via ActualForum NNTP Server 1.4 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.08.2008, 07:33 |
|
|
start [/forum/topic.php?fid=41&msg=35471444&tid=1587424]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
65ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 318ms |
total: | 478ms |
0 / 0 |