topic Re: Hashed Table in Application Development and Automation Discussions

Hashed Table

Former Member — Fri, 05 Jan 2007 03:28:49 GMT

i want to know about hashed table and its uses...

difference between Standard table,Sorted table and Hashed table..

thanks in advance.

Suvetha

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 03:34:52 GMT

Hi Suvetha,

Check these threads it may help you.

Hash table.

Regards,

-Priyanka,.

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 03:36:03 GMT

STANDARD TABLE

Effect

Defines the table as a standard table. Key access to a standard table uses a linear search. This means that the timne required for a search is in linear relation to the number of table entries.

You should use index operations to access standard tables.

For the sake of compatibility, you can use TABLE as a synonym of STANDARD TABLE.

SORTED TABLE

Effect

Defines the table as one that is always saved correctly sorted. Key access to a sorted table uses a binary key. If the key is not unique, the system takes the entry with the lowest index. The runtime required for key access is logarithmically related to the number of table entries.

You can also access sorted tables by index operations. When you insert using an index, the system checks to ensure that the sort sequence has been correctly maintained. For this reason, it takes longer than inserting entries in a standard table. As a rule, you should only access sorted tables using their key.

HASHED TABLE

Effect

Defines the table as one that is managed with an internal hash procedure. You can imagine a hashed table as a set, whose elements you can address using their unique key. Unlike standard and sorted tables, you cannot access hash tables using an index. All entries in the table must have a unique key. Access time using the key is constant, regardless of the number of table entries.

You can only access a hashed table using the generic key operations or other generic operations ( SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM oe INSERT itab within a LOOP) are not allowed.

INDEX TABLE

Effect

Standard and sorted tables belong to the generic class index tables. An index table is one that you can access using an index. You can currently only use the table type INDEX TABLE to specify the type of generic parameters in a FORM or a FUNCTION. Hashed tables are not index tables, and cannot therefore be passed to parameters defined as INDEX TABLE.

ANY TABLE

Effect

Like INDEX TABLE, you use ANY TABLE to specify the type of any generic table parameter. The set of permitted operations for a table with type ANY TABLE consists of the intersection of all permitted operations for STANDARD, SORTED and HASHED TABLEs, and so is identical to the set of operations permitted for hashed tables.

Note in particular that you cannot use index access for tables with this type.

regards

shiba dutta

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 03:37:31 GMT

Hashed table is best suited for big tables..Access time is same for all the rows in hashed table. Meaning you can access the first row or second row or last but one row, it will take the same time.

Hashed table is not suitable for partial key access (Sorted table is better suited for that).

Re: Hashed Table

p291102 — Fri, 05 Jan 2007 03:37:34 GMT

Hi Suvetha mam,

For this basic question u have to first go through thoroughly ABAP IN 21 DAYS -SAMS edition book. In that book all those things are mentioned very clearly Mam.

This book are available in every book stall i thing so mam.

Regards,

Star Shankar

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 03:41:08 GMT

hi Priyanka,

thanks 4r ur helpful answer.

Suvetha

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 03:43:21 GMT

hello Star Shankar sir,

thanks 4r ur valuable hint,,, i wll get that book and study.

Suvetha

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 03:48:23 GMT

hello,

thanks,, but i want 2 know how 2 apply in coding,,

i am giving a material no which should store in Hashed table i wantto know how the output will displayed for it.

Suvetha

Re: Hashed Table

p291102 — Fri, 05 Jan 2007 03:48:43 GMT

Hi Suvetha Mam,

Thanks Welcome Mam.

Thanks,

Star Shankar

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 03:48:59 GMT

Hi Suvetha,

Some general recommendations for internal tables:

• As long as all that you need from an internal table is to append lines to it and perhaps to sort it after filling it, standard tables are still the best choice. The other table kinds are too expen-sive for these simple tasks. Keep in mind that when inserting or deleting lines in index tables containing many lines, the administration of the logical index that manages the lines of the ta-ble internally can become expensive, with regard to performance and additional memory space. Only for standard tables that are filled with APPEND only, and where no lines are de-leted except for the last line, is there no need for a logical index, and hence

no additional costs are incurred.

•If memory space is an issue, for very large internal tables (> 500000 lines) with a

small line size, sorted tables might be preferable to hashed tables, since for internal administration, they need only 6 bytes per line compared to 18 bytes for hashed tables.

•When declaring internal tables, use the addition INITIAL SIZE only for inner tables in nested tables. For outer tables, the automatic allocation of initial memory size is appropriate. For inner tables, though, it may result in saving a large amount of memory.

•When reading internal tables with READ TABLE or LOOP AT, choose the appropriate output behavior. Writing into a work area wa with the addition INTO wa is only necessary if you want to change the work area without influencing the internal table. For pure reading purposes or for modifying the contents of the internal table, the additions ASSIGNING <fs> for assigning internal table lines to a field symbol <fs> and REFERENCE INTO dref for setting a refer-ence in a data reference variable dref to internal table lines are the better choices by far.

•Use CLEAR instead of REFRESH for internal tables. The reason is that for internal tables with-out header lines, the general statement CLEAR does exactly the same as the special state-ment REFRESH. Since internal tables with header lines should no longer be used, the state-ment REFRESH is effectively obsolete. In order to free more memory, you can consider the use of FREE.

•The statement COLLECT should no longer be used for standard tables — use COLLECT mainly for hashed tables. The reason is that COLLECT is based on a hash algorithm. While the hash administration of a hashed table is always available and robust, for standard tables a temporary hash administration must be created when the COLLECT statement is used. This temporary hash administration is invalidated when the table is accessed for changing. If fur-ther COLLECT statements are entered after an invalidation, a linear search of all table rows must be performed. Furthermore, COLLECT only works properly on internal tables with unique lines, while a unique table key is guaranteed for hashed tables only. Therefore, for standard tables it cannot be guaranteed that the contents will always be suitable for editing using COLLECT.

•Don’t use APPEND SORTED BY — use SORT instead. The reason is that creating a ranked list with APPEND SORTED BY is based on several assumptions about the internal table and how it is filled. Using SORT is the general method that can be applied to all kinds of table and inde-pendent from the mode of filling.

Chk these links for more information about internal tables

Regards,

Balaji Reddy G

**Rewards for helpful answers

Re: Hashed Table

Former Member — Fri, 05 Jan 2007 04:01:34 GMT

check this link

<a href="http://help.sap.com/saphelp_470/helpdata/en/d3/2e974d35c511d1829f0000e829fbfe/frameset.htm">http://help.sap.com/saphelp_470/helpdata/en/d3/2e974d35c511d1829f0000e829fbfe/frameset.htm</a>

regards

shiba dutta