using binary search

[Former Member]

Hi All,

I have a sorted table with PERNR as unique key.

The table would contain around 60,000 to 100,000 entries.

Now, when I do a read on the entries, which way would be the best solution.

Is it using BINARY SEARCH or using the Index.

i.e,

READ TABLE IT_ROLECD WITH KEY PERNR = <FS-EMPDETAILS>-PERNR

BINARY SEARCH

INTO WA_ROLECD TRANSPORTING ZROLE_CD.

or

READ TABLE IT_ROLECD WITH KEY PERNR = <FS-EMPDETAILS>-PERNR

INTO WA_ROLECD TRANSPORTING ZROLE_CD.

where IT_ROLECD is a sorted table with PERNR as UNIQUE KEY

[Former Member]

Hi

by useing Binary serach you can find very fast

READ TABLE IT_ROLECD WITH KEY PERNR = <FS-EMPDETAILS>-PERNR

BINARY SEARCH

INTO WA_ROLECD TRANSPORTING ZROLE_CD

because time complexity for this binary serach is n/2

for index it is n

so allways better go for BINARY SEARCH

<b>Reward if usefull</b>

[Former Member]

Thanks a ton Naresh.

This is exactly what I wanted to know

Forgot the logs

[varma_narayana]

Hi Mohan..

Since u have declared the SORTED table there is no need to use the BINARY SEARCH option. When the Condition is on Key field (PERNR) it will always use Binary Search .

So use.

READ TABLE IT_ROLECD WITH KEY PERNR = <FS-EMPDETAILS>-PERNR

INTO WA_ROLECD TRANSPORTING ZROLE_CD.

REWARD IF HELPFUL.

[Former Member]

So, SORTED TABLE always uses BINARY SEARCH is it,

there we dont need to explicitly give BINARY SEARCH ?

[Former Member]

HI,

Sorted internal table is always sorted with the key definition and always binary search..I believe you don't have to give binary search..

Binary search helps incase of standard tables..where you have to sort the internal table with the field and use that field to search the internal table with binary search..

ALso try using the hashed table..where the search time is not dependant on the number of entries in the internal table..

Thanks

Naren

[Former Member]

new answer, conflicts with the previous answer.

[Former Member]

Hi,

check this from the standard sap help..marked in bold.

<b>Standard tables</b>

This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.

<b>Sorted tables</b>

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, <b>since the system always uses a binary search. Sorted tables are particularly useful for partially sequential</b> processing in a LOOP if you specify the beginning of the table key in the WHERE condition.

<b>Hashed tables</b>

This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.

THanks

Naren

[Former Member]

answered

[Former Member]

what happend again u had removed my points

[Former Member]

Dear Naresh,

Please dont mistake me, the answer now becomes a helpful answer, not the complete solution.

I have divided the points to the folks who have also helped in the below posts.

Next time better luck mate.

Take it easy.