reg diff between

[Former Member]

hi

can any one give diff between hashed table,standard table,sorted table,index table,their importance.

thanks in advance

[seshatalpasai_madala]

Hi,

Standard table is something which is used store the data that you want to access using the INDEX.

Hashed table is for storing large amount of data which you want to read mostly and its fastest in access as you access it using the KEY.

Sorted table is both INDEXED as well as KEYED so you can use it store some data which you want to say insert on to the database table.

Standard and Sorted tables are called indexed tables asyou can acess them using the INDEX key word.

Hashed table can only be read using the KEY.

General use:

Sorted: Its generally used for keeping the data that you want to insert into the database.

Hased: used to read large amount of data from the database and keep it locally and want to access them with best performance.

You cannot sort a SORTED table.

Searching a SORTED table uses BINARY search.

Regards,

Sesh

[Former Member]

Standard tables

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 APPENDstatement), 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 (BINARY) with key access, the response time is logarithmically proportional to the number of table entries.

Sorted tables

This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERTstatement. 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, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHEREcondition.

Hashed tables

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.

Sorted tables Also called as INDEX tables .

*Please Mark Use full Answers

[anversha_s]

hi,

Standard Table - the most commonly used type of table. You can sort and resort this table anytime. You can have duplicate records in them. Recommend that when accessing these tables, you sort them by a key and then READ via a BINARY SEARCH - better performance. When you write to this table the record is "appended" to the end of the table. In order to maintain the sort sequence (if any) you must use the SORT command again.

Sorted table - this table has a defined sort sequence. You cannot resort. You can have duplicates. When you READ these tables, SAP automatically tries to use a BINARY SEARCH. Because you use a Binary Search, the retrieval time isexpodential to the number of records. When you write a record to this table the table is resorted.

Hashed Table - this table has a defined key. When you write to the table it uses a hashing algorithm to identify where the record is stored (think if this as writing the location of a page in an index of a book). When you READ this table the system looks up this "index" and retrieves the record. Because of this the retrieval time is constant. Writing to this type of table takes the most time as it needs to calculate the hashing algorithm.

Just go thorugh this link

http://help.sap.com/saphelp_46c/helpdata/EN/fc/eb35de358411d1829f0000e829fbfe/frameset.htm

Regards

Anver

[Former Member]

Siva,

<b>Standard Tables</b>Standard tables offer options that other ABAP table types do not possess. Access via a remote function call (RFC) is a good example. Internally, standard tables build a logical index so that the entries are stored internally in a logical sequence. Access to individual table rows occurs with the index or with the key. Without exception, the key of a standard table is not unambiguous. A great deal of flexibility characterizes standard tables, which is surely one reason why they are the most frequently used table type in ABAP programs.

For example, if a user wants to search with various keys, first with the document number and later in the program with the reference document number, standard tables are ideal. But standard tables offer only inefficient read access because they search through the entire table sequentially. Response time increases linearly with the number of table entries. Users who want more efficiency during read access or when searching with a key must sort the table according to the key and then also use the BINARY SEARCH (READ) function. The table is then searched for the corresponding entry according to the search algorithm of the binary search.

<b>Sorted Tables</b>

A sorted table can’t store any duplicates (entries with more or less the same key). Each entry in a sorted table must have a unique (or unambiguous) key that consists of one or more fields, a document number, a vendor number, or something similar. This table type offers efficient read access that depends only a little upon the size of the table because sorted tables support the execution of binary searches. Insert operations in sorted tables take somewhat longer because the sorting sequence must be maintained.

Sorted tables offer optimization for nested query loops:

LOOP AT TAB1

LOOP AT TAB2 WHERE KEY = TAB1-KEY

• do something

ENDLOOP

ENDLOOP

The example involves two sorted tables; the nested query does not go through all the entries in the second table. The query selects only the values that meet the condition of the key. For example, table 1 contains a list of vendors. Table 2 contains a list of documents (like invoices) that belong to these vendors. The key of the first table would be the vendor number; the key of table 2 would be the document number and vendor number. In this case, the vendor number for table 2 is a partial key. The loop through table 2 ends when the key no longer agrees – when documents of another vendor appear.

For comparison, note that using a standard table would mean always having to go through all the entries in table 2. This situation would require you to optimize the query loop with a break condition – otherwise the operation would have to read all the entries. If the situation involves two tables, one with 100 entries and one with 1,000 entries, a standard table would require 100,000 runs through the loop. Depending on the key condition, using sorted tables drastically reduces that number.

<b>Hash Tables</b>In general, hash tables offer better read performance than standard tables. They should be used to access large quantities of data. The number of entries plays no role because access can occur only with the unambiguous key, one that consists of a document and partner number, for example. Access occurs with a hash algorithm. These algorithms generally deliver an unambiguous output value of a fixed length from input values of any length, which guarantees a constant amount of effort for the access.

The limitation? Access is efficient only when you specify the complete table key. Otherwise performance is similar to that of standard tables: it degrades linearly with the size of the table. Entries in a hash table have a sequence and can be sorted. Hash tables are always a good choice when the data has an unambiguousness key and you can guarantee that the unambiguity remains in effect. This approach is a very good way to map equivalents to a database table in a program.

The bottom line is that developers who stubbornly use only standard table types will quickly find that the program quickly reaches the limits of performance in some circumstances. To avoid poor performance, check each individual case to see which table type makes the most sense for the task at hand.

-Anu