<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: data dictionary--keys in Application Development and Automation Discussions</title>
    <link>https://community.sap.com/t5/application-development-and-automation-discussions/data-dictionary-keys/m-p/3302621#M790795</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The data type of an internal table is fully specified by its:&lt;/P&gt;&lt;P&gt;Line type&lt;/P&gt;&lt;P&gt;The line type defines the attributes of the individual fields. You can specify any ABAP data type.&lt;/P&gt;&lt;P&gt;Key definition&lt;/P&gt;&lt;P&gt;The key fields and their sequence determine the criteria by which the system identifies table lines.&lt;/P&gt;&lt;P&gt;Key type&lt;/P&gt;&lt;P&gt;You can define the key as either unique or non-unique. The uniqueness of the key must be compatible&lt;/P&gt;&lt;P&gt;with the access type you have chosen for the table. If the key is unique, there can be no duplicate&lt;/P&gt;&lt;P&gt;entries in the table.&lt;/P&gt;&lt;P&gt;Access type&lt;/P&gt;&lt;P&gt;Unlike database tables, the system assigns line numbers to certain kinds of internal tables. This means&lt;/P&gt;&lt;P&gt;that you can use the index to access lines as well as the key. We sometimes use the term "table type"&lt;/P&gt;&lt;P&gt;to refer to this.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A unique key is only possible with sorted and hashed tables&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With a standard table, inserting an entry has the same effect as appending. With sorted tables with a nonunique&lt;/P&gt;&lt;P&gt;key, the entry is inserted before the first (if any) entry with the same key.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To read individual data records using the first variant, all fields of &amp;lt;wa1&amp;gt; that are key fields of &amp;lt;itab&amp;gt; must&lt;/P&gt;&lt;P&gt;be filled. &amp;lt;wa1&amp;gt; and &amp;lt;wa2&amp;gt; can be identical. If you use the WITH TABLE KEY addition in the second&lt;/P&gt;&lt;P&gt;variant, you must also specify the key fully. Otherwise, the system searches according to the sequence of&lt;/P&gt;&lt;P&gt;fields that you have specified, using a binary search where possible.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;t_cust_list TYPE TABLE OF t_cust&lt;/P&gt;&lt;P&gt;WITH NON-UNIQUE KEY id.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If you want to access your data using the index and do not need your table to be kept in sorted order or to&lt;/P&gt;&lt;P&gt;have a unique key, that is, when the sequence of the entries is the most important thing, not sorting by&lt;/P&gt;&lt;P&gt;key or having unique entries, you should use standard tables.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;flight_list TYPE SORTED&lt;/P&gt;&lt;P&gt;TABLE OF sflight&lt;/P&gt;&lt;P&gt;WITH UNIQUE KEY carrid connid fldate.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When you choose to use a sorted table, it will normally be because you want to define a unique key. The&lt;/P&gt;&lt;P&gt;mere fact that the table is kept in sorted order is not that significant, since you can sort any kind of internal&lt;/P&gt;&lt;P&gt;table. However, with sorted tables (unlike hashed tables), new data records are inserted in the correct sort&lt;/P&gt;&lt;P&gt;order. If you have a table with few entries but lots of accesses that change the contents, a sorted table&lt;/P&gt;&lt;P&gt;may be more efficient than a hashed table in terms of runtime.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Since the internal table represents a database table in this case, you should ensure that its records have&lt;/P&gt;&lt;P&gt;unique keys.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;t_city_list TYPE HASHED&lt;/P&gt;&lt;P&gt;TABLE OF t_city&lt;/P&gt;&lt;P&gt;WITH UNIQUE KEY city country.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The hash algorithm calculates the address of an entry based on the key. This means that, with larger&lt;/P&gt;&lt;P&gt;tables, the access time is reduced significantly in comparison with a binary search. In a loop, however, the&lt;/P&gt;&lt;P&gt;hashed table has to search the entire table (full table scan). Since the table entries are stored unsorted, it&lt;/P&gt;&lt;P&gt;would be better to use a sorted table if you needed to run a loop through a left-justified portion of the key. It&lt;/P&gt;&lt;P&gt;can also be worth using a hashed table but sorting it.&lt;/P&gt;&lt;P&gt;A typical use for hashed tables is to buffer detailed information that you need repeatedly and can identify&lt;/P&gt;&lt;P&gt;using a unique key.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Hope this is helpful, Do reward.&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Edited by: Runal Singh on Feb 6, 2008 5:46 PM&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 06 Feb 2008 12:16:18 GMT</pubDate>
    <dc:creator>Former Member</dc:creator>
    <dc:date>2008-02-06T12:16:18Z</dc:date>
    <item>
      <title>data dictionary--keys</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/data-dictionary-keys/m-p/3302619#M790793</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;what is difference between unique and non-unique key?plz explain with e.g.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 06 Feb 2008 12:07:41 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/data-dictionary-keys/m-p/3302619#M790793</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-02-06T12:07:41Z</dc:date>
    </item>
    <item>
      <title>Re: data dictionary--keys</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/data-dictionary-keys/m-p/3302620#M790794</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Refer the threads -&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="3878640"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;A class="jive_macro jive_macro_message" href="https://community.sap.com/" __jive_macro_name="message" modifiedtitle="true" __default_attr="3821722"&gt;&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Amit&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 06 Feb 2008 12:10:38 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/data-dictionary-keys/m-p/3302620#M790794</guid>
      <dc:creator>amit_khare</dc:creator>
      <dc:date>2008-02-06T12:10:38Z</dc:date>
    </item>
    <item>
      <title>Re: data dictionary--keys</title>
      <link>https://community.sap.com/t5/application-development-and-automation-discussions/data-dictionary-keys/m-p/3302621#M790795</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;hi,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The data type of an internal table is fully specified by its:&lt;/P&gt;&lt;P&gt;Line type&lt;/P&gt;&lt;P&gt;The line type defines the attributes of the individual fields. You can specify any ABAP data type.&lt;/P&gt;&lt;P&gt;Key definition&lt;/P&gt;&lt;P&gt;The key fields and their sequence determine the criteria by which the system identifies table lines.&lt;/P&gt;&lt;P&gt;Key type&lt;/P&gt;&lt;P&gt;You can define the key as either unique or non-unique. The uniqueness of the key must be compatible&lt;/P&gt;&lt;P&gt;with the access type you have chosen for the table. If the key is unique, there can be no duplicate&lt;/P&gt;&lt;P&gt;entries in the table.&lt;/P&gt;&lt;P&gt;Access type&lt;/P&gt;&lt;P&gt;Unlike database tables, the system assigns line numbers to certain kinds of internal tables. This means&lt;/P&gt;&lt;P&gt;that you can use the index to access lines as well as the key. We sometimes use the term "table type"&lt;/P&gt;&lt;P&gt;to refer to this.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;A unique key is only possible with sorted and hashed tables&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;With a standard table, inserting an entry has the same effect as appending. With sorted tables with a nonunique&lt;/P&gt;&lt;P&gt;key, the entry is inserted before the first (if any) entry with the same key.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;To read individual data records using the first variant, all fields of &amp;lt;wa1&amp;gt; that are key fields of &amp;lt;itab&amp;gt; must&lt;/P&gt;&lt;P&gt;be filled. &amp;lt;wa1&amp;gt; and &amp;lt;wa2&amp;gt; can be identical. If you use the WITH TABLE KEY addition in the second&lt;/P&gt;&lt;P&gt;variant, you must also specify the key fully. Otherwise, the system searches according to the sequence of&lt;/P&gt;&lt;P&gt;fields that you have specified, using a binary search where possible.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;t_cust_list TYPE TABLE OF t_cust&lt;/P&gt;&lt;P&gt;WITH NON-UNIQUE KEY id.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;If you want to access your data using the index and do not need your table to be kept in sorted order or to&lt;/P&gt;&lt;P&gt;have a unique key, that is, when the sequence of the entries is the most important thing, not sorting by&lt;/P&gt;&lt;P&gt;key or having unique entries, you should use standard tables.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;flight_list TYPE SORTED&lt;/P&gt;&lt;P&gt;TABLE OF sflight&lt;/P&gt;&lt;P&gt;WITH UNIQUE KEY carrid connid fldate.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;When you choose to use a sorted table, it will normally be because you want to define a unique key. The&lt;/P&gt;&lt;P&gt;mere fact that the table is kept in sorted order is not that significant, since you can sort any kind of internal&lt;/P&gt;&lt;P&gt;table. However, with sorted tables (unlike hashed tables), new data records are inserted in the correct sort&lt;/P&gt;&lt;P&gt;order. If you have a table with few entries but lots of accesses that change the contents, a sorted table&lt;/P&gt;&lt;P&gt;may be more efficient than a hashed table in terms of runtime.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Since the internal table represents a database table in this case, you should ensure that its records have&lt;/P&gt;&lt;P&gt;unique keys.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;t_city_list TYPE HASHED&lt;/P&gt;&lt;P&gt;TABLE OF t_city&lt;/P&gt;&lt;P&gt;WITH UNIQUE KEY city country.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The hash algorithm calculates the address of an entry based on the key. This means that, with larger&lt;/P&gt;&lt;P&gt;tables, the access time is reduced significantly in comparison with a binary search. In a loop, however, the&lt;/P&gt;&lt;P&gt;hashed table has to search the entire table (full table scan). Since the table entries are stored unsorted, it&lt;/P&gt;&lt;P&gt;would be better to use a sorted table if you needed to run a loop through a left-justified portion of the key. It&lt;/P&gt;&lt;P&gt;can also be worth using a hashed table but sorting it.&lt;/P&gt;&lt;P&gt;A typical use for hashed tables is to buffer detailed information that you need repeatedly and can identify&lt;/P&gt;&lt;P&gt;using a unique key.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;&lt;STRONG&gt;Hope this is helpful, Do reward.&lt;/STRONG&gt;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Edited by: Runal Singh on Feb 6, 2008 5:46 PM&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 06 Feb 2008 12:16:18 GMT</pubDate>
      <guid>https://community.sap.com/t5/application-development-and-automation-discussions/data-dictionary-keys/m-p/3302621#M790795</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2008-02-06T12:16:18Z</dc:date>
    </item>
  </channel>
</rss>

