1

Is it a good practice to sort an internal table (which is already sorted based on three fields) based on one field for the purpose of read table using binary search?

for example:

  SORT itab by field1 field2 field3.
  READ TABLE itab WITH KEY field1 = 'X' 
                           field2 = 'Y' 
                           field3 = 'Z' BINARY SEARCH.
  SORT itab by field1.
  READ TABLE itab WITH KEY field1 = 'X' BINARY SEARCH.

Is it okay if I sort the internal table once again based on field1 to serve for the purpose of second read table statement?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
  • 3
    Very strange question - and I would say, there is no clear answer without more context information. You should never add something if you can't explain why you need it. "Because good practice" is a bad explanation. – vwegert May 16 '17 at 06:04
  • I guess now you got the clear explanation of query. @vwegert – Rajasekharreddy Panditi May 16 '17 at 08:57
  • @vwegert, I cannot imagine a context where this is a good idea – András May 16 '17 at 09:28
  • @András The OP left out so many details - nobody can be sure if he left out some manipulation of the table between the READ operations... – vwegert May 16 '17 at 10:15
  • OP does not know that the table has the correct order after SORT itab BY f1 f2 f3 for BINARY SEARCH WITH KEY f1 f2 f3 / f1 f2 / f1? If really nothing happens inbetween messing up the order... – futu May 16 '17 at 20:02

2 Answers2

1

It is very bad practice

You would get the same result by leaving out the second SORT, but much faster, as the internal table is already in the right order:

SORT itab by field1 field2 field3.
READ TABLE itab WITH KEY field1 = 'X' 
                       field2 = 'Y' 
                       field3 = 'Z' BINARY SEARCH.
READ TABLE itab WITH KEY field1 = 'X' BINARY SEARCH.

Even if the second READ TABLE is by field2, you should leave out the SORT (and of course the BINARY SEARCH too).
Scanning a table from start to finish is linear with the number of lines, but SORT + BINARY SEARCH speed is n+log(n) even in the best case.

András
  • 1,326
  • 4
  • 16
  • 26
  • 1
    The worst case of SORT is n log n, but have you actually measured what it is if the table is already sorted? – vwegert May 16 '17 at 10:14
  • @vwegert, clarified. Even in the best case the SORT is as fast as a full table scan. – András May 16 '17 at 11:47
  • @andras Adding the second sort can give different results if there are multiple entries in the table that have the same value for `field1`. From the documentation for SORT: Sorting is unstable by default, which means that the relative order of rows that do not have different sort keys is not retained when they are sorted, and can change when they are sorted more than once. The addition STABLE can be used for stable sorting. – Gert Beukema May 16 '17 at 20:36
  • @GertBeukema the second sort might give different results, but it is undefined, so OP cannot use or need the new ordering. Hence, useless waste of time. – András May 16 '17 at 22:19
1

It is a bad practice to sort a table to only read one record.

The effort needed for the sort and the read combined is always more than the effort needed to do the one read on an unsorted table.

Gert Beukema
  • 2,510
  • 1
  • 17
  • 18