Hi, Thank you again Cristian. You said that indexing can be worked around although dets doesn't support it. I still searching a way to do it. Can you please tell me how it can be achieved? Are you telling like using B-Tree or some data stucture?   But I don't got a way to combine this B-Tree concept in to Dets table.

<br><br>thanx<br><br>Chamila   <br><br><br><br><div><span class="gmail_quote">On 12/21/06, <b class="gmail_sendername">Christian S</b> <<a href="mailto:chsu79@gmail.com">chsu79@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On 12/21/06, chamila piyasena <<a href="mailto:tchamila@gmail.com">tchamila@gmail.com</a>> wrote: > Thank you again Cristian, > > actually it only stores the CDR records of the SMS(from number, to number ,

<br>> delivered or not, date,  etc.. ) not the SMS it self and a separate dets<br>> file is created every hour .<br>><br>> If some one want to see records  related to a particular phone number in a<br>> given period,  suppose  in  a duration of month  there will be many rows in

<br>> corresponding files.<br>><br>> going through all these records to select what we want is not efficient and<br>> very slow.<br>> thats why I thought about indexing (but there is no support for that in<br>

> dets)<br><br>Are you calling select once per file for every phone number you want a<br>report on? If this is for billing, dont you typically want a report<br>for all phone numbers over the requested period?<br><br>No there is no support for indexing but that can be worked around, but

<br>assuming you still want to scan each hourly dets file:<br><br>I suggest you begin using dets:foldl or dets:foldr  [other readers,<br>what is the difference, order isnt guaranteed anyway?]. Fold doesnt<br>make you have to care about the optimal N. With fold you will process

<br>record after record and it allows you to accumulate information, or<br>perform side effects, such as building up a report file.<br><br>As for working around the lack of indexing. You can add information<br>about the messages stored in an hourly dets file and write that down

before you close it when replacing it with a new one. Just pick a unique dets key to store that information under. Imagine storing the phone numbers seen during the hour, and using this information to see if it is worth scanning the dets file for a given phone number at all.

<br>Imagine using fold as above to keep a report file for each hourly log,<br>a file that maps phone number to a list of the records seen for that<br>number. You can even store that in the same dets file if you make sure<br>

the keys do not collide.<br><br>Similarly, you can keep a map up to date that maps phone numbers to<br>dets files which contain messages with it in. From scanning 30*24 log<br>files, touching ALL data, you will be looking up a phone number to

<br>find which dets files it has contributed to. And then looking up the<br>phone number in those dets files to find which records that was. Only<br>touching a fraction of the log data.<br></blockquote></div><br>