Difference between unique constraint and unique index

1. What is the difference between unique constraint and unique index when unique constraint is always indexed ? Which one is better in this case for better performance ?
2. Is Composite index of 3 columns x,y,z better
or having independent/ seperate indexes on 3 columns x,y,z is better for better performance ?
3. It has been very confusing for me to decide which columns to index, I have indexed most foreignkey columns, is it a good idea ? We do lot of selects and DMLS on most of our tables. Is there any query that I can run and find out if indexes are really being used and if they are improving any performance. I have analyzed and computed my indexes using ANALYZE index index_name validate structure and COMPUTE STATISTICS;
null

1. Unique index is part of unique constraint. Of course you can create standalone unique index. But is is no point to skip the logical view of business if you spend same effort to achive.
You create unique const. Oracle create the unique index for you. You may specify index characteristic in unique constraint.
2. Depends. You can't utilize the composite index if the searching condition is not whole or front part of the indexing key. You can't utilize your index if you query the table for y=2. That is.
3. As old words in database arena, Index may be good or bad for a table depending on the size of table, number of columns in the table... etc. It is very environmental dependent. In fact, It is part of database nomalization. Statistic is a way oracle use to determine the execution plan.
Steve
null

Similar Messages

  • Difference between PRIMARY KEY and UNIQUE KEY with NOT NULL

    What is the difference between PRIMARY KEY and UNIQUE KEY with NOT NULL constraint?
    Message was edited by:
    Nilesh Hole

    Answer for the master!!!
    http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:8743855576462
    Thanks,
    Karthick

  • Difference between primary key and primary index

    Dear All,
             Hi... .Could you pls tell me the difference between primary key and primary index.
    Thanks...

    Hi,
    Primary Key : It is one which makes an entry of the field unique.No two distinct rows in a table can have the same value (or combination of values) in those columns.
    Eg: first entry is 111, if you again enter value 111 , it doesnot allow 111 again. similarly for the strings or characters or numc etc. Remember that for char or numc or string 'NAME' is not equal to 'name'.
    Primary Index: this is related to the performance .A database index is a data structure that improves the speed of operations in a table. Indices can be created using one or more columns, providing the basis for both rapid random lookups and efficient ordering of access to records. The disk space required to store the index is typically less than the storage of the table (since indices usually contain only the key-fields according to which the table is to be arranged, and excludes all the other details in the table), yielding the possibility to store indices into memory from tables that would not fit into it. In a relational database an index is a copy of part of a table. Some databases extend the power of indexing by allowing indices to be created on functions or expressions. For example, an index could be created on upper(last_name), which would only store the uppercase versions of the last_name field in the index.
    In a database , we may have a large number of records. At the time of retrieving data from the database based on a condition , it is a burden to the db server. so whenever we create a primary key , a primary index is automatically created by the system.
    If you want to maintain indices on other fields which are frequently used in where condition then you can create secondary indices.
    Reward points if helpful.
    Thanks,
    Sirisha..

  • Difference between sy-tabix and sy-index?

    tell me about sy-tabix and sy-index?what is the difference between sy-tabix and sy-index?
    Moderator Message: Please search before posting. Read the [Forum Rules Of Engagement |https://wiki.sdn.sap.com/wiki/display/HOME/RulesofEngagement] for further details.
    Edited by: Suhas Saha on Jun 18, 2011 5:33 PM

    HI,
        Here is a brief description of difference between SY_TABIX and SY_INDEX and using them with several conditions.
    SY-TABIX
    Current line of an internal table. SY-TABIX is set by the statements below, but only for index tables. The field is either not set or is set to 0 for hashed tables.
    APPEND sets SY-TABIX to the index of the last line of the table, that is, it contains the overall number of entries in the table.
    COLLECT sets SY-TABIX to the index of the existing or inserted line in the table. If the table has the type HASHED TABLE, SY-TABIX is set to 0.
    LOOP AT sets SY-TABIX to the index of the current line at the beginning of each loop lass. At the end of the loop, SY-TABIX is reset to the value that it had before entering the loop. It is set to 0 if the table has the type HASHED TABLE.
    READ TABLE sets SY-TABIX to the index of the table line read. If you use a binary search, and the system does not find a line, SY-TABIX contains the total number of lines, or one more than the total number of lines. SY-INDEX is undefined if a linear search fails to return an entry.
    SEARCH <itab> FOR sets SY-TABIX to the index of the table line in which the search string is found.
    SY-INDEX
    In a DO or WHILE loop, SY-INDEX contains the number of loop passes including the current pass.
    Hope this helps.
    Thank you,
    Pavan.

  • Difference between primary eindex and secondary index?

    hi experts
    pls answer me
    difference between primary eindex and secondary index?
    rewads apply.
    thanks.
    naresh.

    hi,
    check this link.
    http://help.sap.com/saphelp_47x200/helpdata/en/cf/21eb2d446011d189700000e8322d00/frameset.htm
    A difference is made between Primary & Secondary indexes to a table. the primary index consists of the key fields of the table and a pointer to the non-keys-fields of the table. The Primary index is generated automatically when a table is created and is created in the datebase as the same times as the table. It is also possible to define further indexes to a table in the ABAP/4 dictionary, which are then referred to as Secondary indexes.
    Always it is not mandatory that an index should have all the key fields of a table. To see the index of a table
    goto SE11->specify table name->click on the indexes... button on the application toolbar.
    Based on your requirement you can you any of those index fields in the where clause of your query. Always its a better practice to use the index fields in the order specified. While selecting the records from a table it is always better to select the fields in the same order as specified in the table.

  • Difference between Primary Key and Unique Key with NOT NULL constraint

    As both can be referred to another table.
    Apart from the difference that Primary Key can be only 1 and Unique keys can be multiple,
    is there any difference?
    Like in terms of type of Index?

    PARAG_C wrote:
    As both can be referred to another table.
    Apart from the difference that Primary Key can be only 1 and Unique keys can be multiple,
    is there any difference?
    Like in terms of type of Index?Technically there is almost no difference. Logically the two are often used for slightly different concepts.
    The PK (and with it the index) is often an ID column filled by a seqeunce. This key can then be refenced by foreign key constraints on other tables. it is very useful to have this as a meaningless technical construct. Because then the chance that such a ID needs to be changed is extremly slim.
    The UK (and with it the index) is often one or several columns that represent the logical key for the entity. Foreign key constriants should not point to this. THe chance that this attribute will be changed at some point in time is way higher then for a meaningless number (ID).

  • Access path difference between Primary Key and Unique Index

    Hi All,
    Is there any specific way the oracle optimizer treats Primary key and Unique index differently?
    Oracle Version
    SQL> select * from v$version;
    BANNER
    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    PL/SQL Release 11.2.0.3.0 - Production
    CORE    11.2.0.3.0      Production
    TNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - Production
    NLSRTL Version 11.2.0.3.0 - Production
    SQL> Sample test data for Normal Index
    SQL> create table t_test_tab(col1 number, col2 number, col3 varchar2(12));
    Table created.
    SQL> create sequence seq_t_test_tab start with 1 increment by 1 ;
    Sequence created.
    SQL>  insert into t_test_tab select seq_t_test_tab.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
    99999 rows created.
    SQL> commit;
    Commit complete.
    SQL> exec dbms_stats.gather_table_stats(USER_OWNER','T_TEST_TAB',cascade => true);
    PL/SQL procedure successfully completed.
    SQL> select col1 from t_test_tab;
    99999 rows selected.
    Execution Plan
    Plan hash value: 1565504962
    | Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |            | 99999 |   488K|    74   (3)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
           6915  consistent gets
            259  physical reads
              0  redo size
        1829388  bytes sent via SQL*Net to client
          73850  bytes received via SQL*Net from client
           6668  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          99999  rows processed
    SQL> create index idx_t_test_tab on t_test_tab(col1);
    Index created.
    SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB',cascade => true);
    PL/SQL procedure successfully completed.
    SQL> select col1 from t_test_tab;
    99999 rows selected.
    Execution Plan
    Plan hash value: 1565504962
    | Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |            | 99999 |   488K|    74   (3)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
           6915  consistent gets
              0  physical reads
              0  redo size
        1829388  bytes sent via SQL*Net to client
          73850  bytes received via SQL*Net from client
           6668  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          99999  rows processed
    SQL> Sample test data when using Primary Key
    SQL> create table t_test_tab1(col1 number, col2 number, col3 varchar2(12));
    Table created.
    SQL> create sequence seq_t_test_tab1 start with 1 increment by 1 ;
    Sequence created.
    SQL> insert into t_test_tab1 select seq_t_test_tab1.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
    99999 rows created.
    SQL> commit;
    Commit complete.
    SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB1',cascade => true);
    PL/SQL procedure successfully completed.
    SQL> select col1 from t_test_tab1;
    99999 rows selected.
    Execution Plan
    Plan hash value: 1727568366
    | Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |             | 99999 |   488K|    74   (3)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| T_TEST_TAB1 | 99999 |   488K|    74   (3)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
           6915  consistent gets
              0  physical reads
              0  redo size
        1829388  bytes sent via SQL*Net to client
          73850  bytes received via SQL*Net from client
           6668  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          99999  rows processed
    SQL> alter table t_test_tab1 add constraint pk_t_test_tab1 primary key (col1);
    Table altered.
    SQL> exec dbms_stats.gather_table_stats('USER_OWNER','T_TEST_TAB1',cascade => true);
    PL/SQL procedure successfully completed.
    SQL> select col1 from t_test_tab1;
    99999 rows selected.
    Execution Plan
    Plan hash value: 2995826579
    | Id  | Operation            | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |                | 99999 |   488K|    59   (2)| 00:00:01 |
    |   1 |  INDEX FAST FULL SCAN| PK_T_TEST_TAB1 | 99999 |   488K|    59   (2)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
           6867  consistent gets
              0  physical reads
              0  redo size
        1829388  bytes sent via SQL*Net to client
          73850  bytes received via SQL*Net from client
           6668  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          99999  rows processed
    SQL> If you see here the even though statistics were gathered,
         * In the 1st table T_TEST_TAB, the table is still using FULL table access after creation of index.
         * And in the 2nd table T_TEST_TAB1, table is using PRIMARY KEY as expected.
    Any comments ??
    Regards,
    BPat

    Thanks.
    Yes, ignored the NOT NULL part.Did a test and now it is working as expected
    SQL>  create table t_test_tab(col1 number not null, col2 number, col3 varchar2(12));
    Table created.
    SQL>
    create sequence seq_t_test_tab start with 1 increment by 1 ;SQL>
    Sequence created.
    SQL> insert into t_test_tab select seq_t_test_tab.nextval, round(dbms_random.value(1,999)) , 'B'||round(dbms_random.value(1,50))||'A' from dual connect by level < 100000;
    99999 rows created.
    SQL> commit;
    Commit complete.
    SQL>  exec dbms_stats.gather_table_stats('GREP_OWNER','T_TEST_TAB',cascade => true);
    PL/SQL procedure successfully completed.
    SQL>  set autotrace traceonly
    SQL>  select col1 from t_test_tab;
    99999 rows selected.
    Execution Plan
    Plan hash value: 1565504962
    | Id  | Operation         | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |            | 99999 |   488K|    74   (3)| 00:00:01 |
    |   1 |  TABLE ACCESS FULL| T_TEST_TAB | 99999 |   488K|    74   (3)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
           6912  consistent gets
              0  physical reads
              0  redo size
        1829388  bytes sent via SQL*Net to client
          73850  bytes received via SQL*Net from client
           6668  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          99999  rows processed
    SQL>  create index idx_t_test_tab on t_test_tab(col1);
    Index created.
    SQL>  exec dbms_stats.gather_table_stats('GREP_OWNER','T_TEST_TAB',cascade => true);
    PL/SQL procedure successfully completed.
    SQL>  select col1 from t_test_tab;
    99999 rows selected.
    Execution Plan
    Plan hash value: 4115006285
    | Id  | Operation            | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT     |                | 99999 |   488K|    63   (2)| 00:00:01 |
    |   1 |  INDEX FAST FULL SCAN| IDX_T_TEST_TAB | 99999 |   488K|    63   (2)| 00:00:01 |
    Statistics
              1  recursive calls
              0  db block gets
           6881  consistent gets
              0  physical reads
              0  redo size
        1829388  bytes sent via SQL*Net to client
          73850  bytes received via SQL*Net from client
           6668  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
          99999  rows processed
    SQL>

  • Difference between Primary Key and Unique+Not NUll

    Hi Guys,
    Is there any difference the column being declared as primary key or unique+NOT NULL.
    Please let me know the internal and application point of view.
    Thanks in advance!
    Ranjan

    957590 wrote:
    Ok,Thanks however I donot think Primary key uses unique indexPK uses whatever index you specify - unique or not (as long as index is on proper column(s)). However, if you do not specify any index, PK creates unique index:
    SQL> create table tbl(
      2                   id number,
      3                   name varchar2(10)
      4                  )
      5  /
    Table created.
    SQL> alter table tbl
      2    add constraint tbl_pk
      3      primary key(
      4                  id
      5                 )
      6  /
    Table altered.
    SQL> select  index_name,
      2          uniqueness
      3    from  user_indexes
      4    where table_name = 'TBL'
      5  /
    INDEX_NAME                     UNIQUENES
    TBL_PK                         UNIQUE
    SQL> select  constraint_name,
      2          index_name
      3    from  user_constraints
      4    where table_name = 'TBL'
      5  /
    CONSTRAINT_NAME                INDEX_NAME
    TBL_PK                         TBL_PK
    SQL>  alter table tbl
      2    drop primary key
      3  /
    Table altered.
    SQL> create index tbl_non_unique_pk_index
      2    on tbl(
      3           id
      4          )
      5  /
    Index created.
    SQL> alter table tbl
      2    add constraint tbl_pk
      3      primary key(
      4                  id
      5                 )
      6        using index tbl_non_unique_pk_index
      7  /
    Table altered.
    SQL> select  index_name,
      2          uniqueness
      3    from  user_indexes
      4    where table_name = 'TBL'
      5  /
    INDEX_NAME                     UNIQUENES
    TBL_NON_UNIQUE_PK_INDEX        NONUNIQUE
    SQL> select  constraint_name,
      2          index_name
      3    from  user_constraints
      4    where table_name = 'TBL'
      5  /
    CONSTRAINT_NAME                INDEX_NAME
    TBL_PK                         TBL_NON_UNIQUE_PK_INDEX
    SQL> insert
      2    into tbl
      3    values(
      4           1,
      5           'A'
      6          )
      7  /
    1 row created.
    SQL> insert
      2    into tbl
      3    values(
      4           2,
      5           'B'
      6          )
      7  /
    1 row created.
    SQL> insert
      2    into tbl
      3    values(
      4           1,
      5           'C'
      6          )
      7  /
    insert
    ERROR at line 1:
    ORA-00001: unique constraint (SCOTT.TBL_PK) violated
    SQL> SY.

  • What is difference between sy-tabix and sy-index.

    SAP Seniors,
    Can you please let me know what is difference between sy-index and sy-tabix.
    I read the SAP help, it is confusing for me. it looks like both are same from help. please help me.
    Thank you
    Anitha.

    HI,
        Here is a brief description of difference between SY_TABIX and SY_INDEX and using them with several conditions.
    SY-TABIX
    Current line of an internal table. SY-TABIX is set by the statements below, but only for index tables. The field is either not set or is set to 0 for hashed tables.
    APPEND sets SY-TABIX to the index of the last line of the table, that is, it contains the overall number of entries in the table.
    COLLECT sets SY-TABIX to the index of the existing or inserted line in the table. If the table has the type HASHED TABLE, SY-TABIX is set to 0.
    LOOP AT sets SY-TABIX to the index of the current line at the beginning of each loop lass. At the end of the loop, SY-TABIX is reset to the value that it had before entering the loop. It is set to 0 if the table has the type HASHED TABLE.
    READ TABLE sets SY-TABIX to the index of the table line read. If you use a binary search, and the system does not find a line, SY-TABIX contains the total number of lines, or one more than the total number of lines. SY-INDEX is undefined if a linear search fails to return an entry.
    SEARCH <itab> FOR sets SY-TABIX to the index of the table line in which the search string is found.
    SY-INDEX
    In a DO or WHILE loop, SY-INDEX contains the number of loop passes including the current pass.
    Hope this helps.
    Thank you,
    Pavan.

  • What is the difference between "Invisible" (11g) and "virtual" index?

    Hi
    What is the difference between the "Invisible" index and "virtual" index?
    Thanks
    Balaji

    Indexes can be visible or invisible. An invisible index is maintained by DML operations and cannot be used by the optimizer. Actually takes space, but is not to be used as part of a potential access path.
    AFAIK, a virtual index is created by the tools used in SQL statement access path tuning to provide an alternative for the optimizer to test. It does not take any real space as it is a pure in memory definition.

  • Is their a difference between primary key and unique key with not null valu

    What is the difference in having a column as primary key and having unique key with not null for the column.
    vinodh

    SBH wrote:
    For quick review, below is the link
    http://www.dba-oracle.com/data_warehouse/clustered_index.htm
    You appear to have stumbled on a site that is a mine of disinformation about Oracle.
    >
    It would be helpful, if you explain it too..thnx !!
    The site is wrong and makes up its own terminology as it goes along.
    If the value for clustering factor approaches the number of blocks in the base table, then the index is said to be clustered. http://www.oracle.com/pls/db112/search?remark=quick_search&word=clustered+index
    There is no create clustered index in Oracle.
    - Clustering factor affects the efficiency of an index.
    - There can be clustered tables that you can create indexes on.
    - An Index Organized table is a similar concept to the Microsoft SQL Server clustered index, but it isn't the same thing at all.

  • What is the difference between Topic Keywords and Index File Keywords?

    What is the difference between Topic Keywords and Index File Keywords? Any advantages to using one over the other? Do they appear differently in the generated index?
    RH9.0.2.271
    I'm using Webhelp

    Hi there
    When you create a RoboHelp project you end up with many different ancillary files that are used to store different bits of information. Many of these files bear the name you assigned to the project at the time you created it. The index file has the project name and it ends with a .HHK file extension. (HHK meaning HTML Help Keywords)
    Generally, unless you change RoboHelp's settings, you add keywords to this file and associate topics to the keywords via the Index pod. At the time you compile a CHM or generate other types of output, the file is consulted and the index is built.
    As I said earlier, the default is to add keywords to the Index file until you configure RoboHelp to add the keywords to the topics themselves. Once you change this, any keyword added will become a META tag in the topic code. If your keyword is BOFFO, the META tag would look like this:
    <meta name="MS-HKWD" content="BOFFO" />
    When the help is compiled or generated, the Index (.HHK) file is consulted as normal, but any topics containing keywords added in this manner are also added to the Index you end up with. From the appearance perspective, the end user woudn't know the difference or be able to tell. Heck, if all you ever did was interact with the Index pod, you, as an author wouldn't know either. Well, other than the fact that the icons appear differently.
    Operationally, keywords added to the topics themselves may hold an advantage in that if you were to import these topics into other projects, the Index keywords would already be present.
    Hopefully this helps... Rick

  • Difference between open loop and closed loop mode when finding the index on a stepper motor axis.

    I have a test system which uses a PXI-7352 motion controller with a MID-7602 stepper motor drive to position a 200 step/revolution stepper motor with an attached 1000 line encoder.  The MID-7602 is configured for 64 microsteps per step, giving 12,800 microsteps and 4000 encoder counts per revolution.  The system is controlled using LabView 7.1 and NI-Motion 6.13.  To home the motor, I've defined a sequence in MAX which first finds the reverse limit switch and then moves forward to the encoder index pulse.
    When finding its reference in open loop mode, the system its reference at the same microstep each time.  When findings its reference in closed loop mode, the system finds its reference somewhere within about a 20 microstep wide range.
    I hope somebody out there with more experience with this controller can describe the difference between finding the encoder index in open loop mode and finding the encoder index in closed loop mode. 
    Thanks,
    Mark Moss

    Hello Mark,
    I suspect that the behavior you are experiencing has today
    with the resolution difference between your encoder and your
    microstepping.  Let me illustrate with an
    example:
    Example Setup
    Stepper
    Motor
    NI
    Motion Controller
    10
    steps per encoder pulse (Every 10 steps the controller gets an encoder
    pulse, therefore positions 0-9 all appear to be 0 to the controller)
    The
    system has a maximum of 3 pull in moves set
    Open Loop Scenario
    The
    system is commanded to go to position 9.
    The
    controller sends out 9 pulses.
    The
    motor moves to position 9.
    Closed Loop Scenario
    The
    system is commanded to go to position 9.
    The
    controller sends out 9 pulses.
    The
    motor moves to position 9.
    The
    controller checks its position and sees that it is still at position 0
    because it has not received an encoder pulse.
    Because
    the controller thinks it is still at position 0, it sends another 9 pulses
    as its first pull in move.
    The
    motor moves to position 18.
    The
    controller checks its position and sees that it is at position 10 because
    it has only received one encoder pulse.
    Because
    the controller thinks it is still at position 10, it sends1 reverse pulse
    as its second pull in move.
    The
    motor moves to position 17.
    The
    controller checks its position and sees that it is at position 10 because
    it has only received one encoder pulse.
    Because
    the controller thinks it is still at position 10, it sends and additional
    single reverse pulse as its third pull in move.
    The
    motor moves to its final position of 16.
    I believe something similar is happening with your
    application as it looks for the index pulse. 
    Because the controller does not compensate for what it perceives as
    position error in open loop mode, the motor always goes to the same commanded
    position.  In closed loop mode, the motor
    is bouncing around inside the single index encoder pulse trying to find a
    certain position.
    There are several recommendations I can make towards
    correcting this behavior.  These
    recommendations are in order of effectiveness:
    Setup
    your system so that there are more encoder counts per revolution than
    steps per revolution.
    Turn
    off pull-in moves by setting them to 0 in MAX.
    Use an
    open loop configuration.
    Play
    around with the pull in window in MAX.
    Regards,
    Luke H

  • What is the difference between standard,sorted and hash table

    <b>can anyone say what is the difference between standard,sorted and hash tabl</b>

    Hi,
    Standard Tables:
    Standard tables have a linear index. You can access them using either the index or the key. If you use the key, the response time is in linear relationship to the number of table entries. The key of a standard table is always non-unique, and you may not include any specification for the uniqueness in the table definition.
    This table type is particularly appropriate if you want to address individual table entries using the index. This is the quickest way to access table entries. To fill a standard table, append lines using the (APPEND) statement. You should read, modify and delete lines by referring to the index (INDEX option with the relevant ABAP command). The response time for accessing a standard table is in linear relation to the number of table entries. If you need to use key access, standard tables are appropriate if you can fill and process the table in separate steps. For example, you can fill a standard table by appending records and then sort it. If you then use key access with the binary search option (BINARY), the response time is in logarithmic relation to
    the number of table entries.
    Sorted Tables:
    Sorted tables are always saved correctly sorted by key. They also have a linear key, and, like standard tables, you can access them using either the table index or the key. When you use the key, the response time is in logarithmic relationship to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique, or non-unique, and you must specify either UNIQUE or NON-UNIQUE in the table definition. Standard tables and sorted tables both belong to the generic group index tables.
    This table type is particularly suitable if you want the table to be sorted while you are still adding entries to it. You fill the table using the (INSERT) statement, according to the sort sequence defined in the table key. Table entries that do not fit are recognised before they are inserted. The response time for access using the key is in logarithmic relation to the number of
    table entries, since the system automatically uses a binary search. Sorted tables are appropriate for partially sequential processing in a LOOP, as long as the WHERE condition contains the beginning of the table key.
    Hashed Tables:
    Hashes tables have no internal linear index. You can only access hashed tables by specifying the key. The response time is constant, regardless of the number of table entries, since the search uses a hash algorithm. The key of a hashed table must be unique, and you must specify UNIQUE in the table definition.
    This table type is particularly suitable if you want mainly to use key access for table entries. You cannot access hashed tables using the index. When you use key access, the response time remains constant, regardless of the number of table entries. As with database tables, the key of a hashed table is always unique. Hashed tables are therefore a useful way of constructing and
    using internal tables that are similar to database tables.
    Regards,
    Ferry Lianto

  • Difference between Database, instance and schema

    Hi
    I don't know the clear difference between database, instance and schema.. In the broad sense, everything seems to be the same. If anyone can differentiate between them with some example, that will be of great help.
    Thank you.

    Hi,
    In Oracle, people often do use "database" and "instance" interchangeably, or together as one term: "database instance".
    A "schema" is quite different. A schema is a collection of objects (such as tables, indexes or procedures). Every object belongs to exactly one schema, and every schema is a part of exactly one database. (Names may not be unique, however. For example, your database may have one schema named SCOTT, and another schema named USER1. Each of those schemas may have a table named EMP. The EMP table in the SCOTT schema, or SCOTT.EMP, is not the same as the EMP table in the USER1 schema, or USER1.EMP. A different database, my database for example, may also have schemas called SCOTT and USER1, which are completely independent of the SCOTT and USER1 in your database.)

Maybe you are looking for