Views Vs Database Tables

Former Member — Tue, 28 Aug 2007 08:14:03 GMT

What is better to use - Views or Database Tables

Re: Views Vs Database Tables

Former Member — Tue, 28 Aug 2007 08:16:25 GMT

Hi,

<b>VIEWS</b>

There are 4 types.

Database View (SE11)

Database views are implement an inner join, that is, only records of the primary table (selected via the join operation) for which the corresponding records of the secondary tables also exist are fetched. Inconsistencies between primary and secondary table could, therefore, lead to a reduced selection set.

In database views, the join conditions can be formulated using equality relationships between any base fields. In the other types of view, they must be taken from existing foreign keys. That is, tables can only be collected in a maintenance or help view if they are linked to one another via foreign keys.

- Help View ( SE54)

Help views are used to output additional information when the online help system is called.

When the F4 button is pressed for a screen field, a check is first made on whether a matchcode is defined for this field. If this is not the case, the help view is displayed in which the check table of the field is the primary table. Thus, for each table no more than one help view can be created, that is, a table can only be primary table in at most one help view.

- Projection View

Projection views are used to suppress or mask certain fields in a table (projection), thus minimizing the number of interfaces. This means that only the data that is actually required is exchanged when the database is accessed.

A projection view can draw upon only one table. Selection conditions cannot be specified for projection views.

- Maintenance View ( SE54 )

Maintenance views enable a business-oriented approach to looking at data, while at the same time, making it possible to maintain the data involved. Data from several tables can be summarized in a maintenance view and maintained collectively via this view. That is, the data is entered via the view and then distributed to the underlying tables by the system.

Please have a look at below link. It will help you.

http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ed06446011d189700000e8322d00/frameset.htm

for more detailed info look on:

http://www.sap-img.com/abap/what-is-the-different-types-and-usage-of-views.htm

https://www.sdn.sap.com/irj/sdn/wiki?path=/display/home/abap+dictionary&;

<b>TABLES</b>

Pool Tables

1) Many to One Relationship.

2) Table in the Dictionary has the different name, different number of fields, and the fields have the different name as in the R3 Table definition.

3) It can hold only pooled tables.

cluster Tables:

1) These are logical tables that are arranged as records of transparent tables.

2) One cannot use Native SQL on these tables (only Open SQL).

3) They are not manageable directly using database system tools.

These two table are used to store system data and onother for configural data.

if u want to fetch the data from DB table u need to go for trasperent tables only.

Bcoz transperent tables are one - one relation.

Refer to this link

http://help.sap.com/saphelp_nw04/helpdata/en/81/415d363640933fe10000009b38f839/frameset.htm

INTERNAL TABLES

There are 3 types of Internal tables.

Standard Internal 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 Internal 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 Internal 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,

Priyanka.

Re: Views Vs Database Tables

Former Member — Tue, 28 Aug 2007 10:21:03 GMT

Hi,

It is better to use always Database table while selecting data.

view is virtual table means physically it does not contain any data, while running the program it get data from database table and keep the data into view on RAM, once if you close the program, it voilate them.

This view is useful when you want to select a data from multiples of tables.

Reward with points if it helpful.

Regards,

Vijay.

Re: Views Vs Database Tables

Former Member — Tue, 28 Aug 2007 15:29:13 GMT

Hi Disha,

It depends on the requirement for transactional data it always better to use databse table because transactional data will always be changing so its better to use it. in case of master data table if we frequenetly need few important fields used by so many programs then in that case we can use VIEWS because it will minimise the load on database server...

Reward points if it helped

Thanks and regards

Tanweer

topic Re: Views Vs Database Tables in Application Development and Automation Discussions

Views Vs Database Tables

Re: Views Vs Database Tables

Re: Views Vs Database Tables

Re: Views Vs Database Tables