Among the various features provided by ABAP, I find LDB concept quite interesting. There has been always a debate about LDB’s usability, performance and where it should be used. I would like to share some information about LDB’s in this blog. A case where LDB’s could be used: If there exists a hierarchy among tables defined by foreign key relationships then one can define a relationship between tables using LDB’s. In this section I would like to explain two cases where LDB’s usage is justified. I have found the below example in one of the websites which gives a clear requirement where use of LDB makes sense. Case1: Suppose my company manufactures widgets of the most obscure variety, and they are components of other widgets. I sell my widgets as raw material for the more sophisticated widgets built by others, but in some cases I actually partner with other manufacturers in creating yet another class of widget. Now, in my world, I consequently have customers who are also partners. I sell to them and I partner with them in manufacturing and distribution. Also, I need an application that uses both of these dual-use relationships. Essentially, I have a customer database and a partner database. Neither contains records that are structured to contain the identifying particulars of the other. Thus, I need a hybrid database that gives me tables detailing these hybrid relationships. What can I do? I can go the long way around and write a new database, pulling information from both and creating new objects with a customized program that I write by hand. However, this process is cumbersome and contains maintenance issues. On the other hand, I can use Sap’s logical database facility, create my logical database in a couple of minutes, and have no maintenance issues at all. Case2. Here I have shown below a LDB of Deals which is used in FICO-TR module. 
Most of the fields in nodes such as NPV Values, Int. Rate Adjustment Data etc. are populated from various tables and involves complex calculations. (This LDB queries on more than 30 tables).There are many reports in Treasury Area which use this LDB of Deals. Infact, I have developed few where I used the LDB’s available and I don’t need to know the underlying complexity of retrieving data. Data Processing with LDB’s: Find below various ways of using LDB’s. 
LDB’s can be used with: - SAP Standard Reporting Tools such as SAP Query / Quick Viewer / Info Set Query. Also it’s easy to enhance by additional tables/fields in the Info set. - BW: there are Data Source-Generators for Info sets on LDBs - Some external Reporting-Tools like Crystal Reports have Interfaces to LDBs/Info sets - LDB’s can be used as internal data selector using function module LDB_PROCESS Advantages of LDB Just a quick view at the advantages of LDB: • Reading the same data for several reports Individual reports no longer need to know the relevant database tables and foreign key relationships which involve complex joins. They can rely on LDB’s to get data. I find this feature very useful. • Default user interface Logical databases come with a built-in selection screen. Therefore, all of the programs that use the logical database have the same user interface. Additional select options could be added in the usual way by defining them in report. Also, unnecessary select options could be hidden using Loop at Screen Logic. • Central authorization checks Authorization checks can be programmed centrally in the database to prevent them from being bypassed by simple application programs. Disadvantages of LDB Disadvantages would creep in when LDB’s are not designed logically. • If the data required could be obtained with few select statements then it would be overhead to have an LDB. In this case, it would be better not to go for LDB’s. • The use of very large tables will degrade the performance of a logical database. • Also I have seen few LDB’s (For Ex. LDB of PSJ .Pardon me if iam wrong) which are designed way too complex with a huge number of nodes and in this case I suspect degradation in performance. • Also, since many application programs could use LDB’s, special measures should be taken while programming to improve response times else this would affect other programs too. Thus, logically designed LDB’s would always provide a means for powerful, flexible and easy reporting environment hiding the complexity and reducing a great deal of overhead. Although creating a huge LDB could be an overhead, if the reporting requirements need it, then I feel it’s a good investment to do it. Then, why not a Logical Database? Finally, some links which would give more information about LDB’s: http://help.sap.com/saphelp_46c/helpdata/en/9f/db9b5e35c111d1829f0000e829fbfe/content.htm http://www.thespot4sap.com/articles/SAP_ABAP_Queries_FunctionalAreas_WithoutLogicalDB.asp Food for thought: LDBs and ABAP Objects
Most of the fields in nodes such as NPV Values, Int. Rate Adjustment Data etc. are populated from various tables and involves complex calculations. (This LDB queries on more than 30 tables).There are many reports in Treasury Area which use this LDB of Deals. Infact, I have developed few where I used the LDB’s available and I don’t need to know the underlying complexity of retrieving data. Data Processing with LDB’s: Find below various ways of using LDB’s. LDB’s can be used with: - SAP Standard Reporting Tools such as SAP Query / Quick Viewer / Info Set Query. Also it’s easy to enhance by additional tables/fields in the Info set. - BW: there are Data Source-Generators for Info sets on LDBs - Some external Reporting-Tools like Crystal Reports have Interfaces to LDBs/Info sets - LDB’s can be used as internal data selector using function module LDB_PROCESS Advantages of LDB Just a quick view at the advantages of LDB: • Reading the same data for several reports Individual reports no longer need to know the relevant database tables and foreign key relationships which involve complex joins. They can rely on LDB’s to get data. I find this feature very useful. • Default user interface Logical databases come with a built-in selection screen. Therefore, all of the programs that use the logical database have the same user interface. Additional select options could be added in the usual way by defining them in report. Also, unnecessary select options could be hidden using Loop at Screen Logic. • Central authorization checks Authorization checks can be programmed centrally in the database to prevent them from being bypassed by simple application programs. Disadvantages of LDB Disadvantages would creep in when LDB’s are not designed logically. • If the data required could be obtained with few select statements then it would be overhead to have an LDB. In this case, it would be better not to go for LDB’s. • The use of very large tables will degrade the performance of a logical database. • Also I have seen few LDB’s (For Ex. LDB of PSJ .Pardon me if iam wrong) which are designed way too complex with a huge number of nodes and in this case I suspect degradation in performance. • Also, since many application programs could use LDB’s, special measures should be taken while programming to improve response times else this would affect other programs too. Thus, logically designed LDB’s would always provide a means for powerful, flexible and easy reporting environment hiding the complexity and reducing a great deal of overhead. Although creating a huge LDB could be an overhead, if the reporting requirements need it, then I feel it’s a good investment to do it. Then, why not a Logical Database? Finally, some links which would give more information about LDB’s: http://help.sap.com/saphelp_46c/helpdata/en/9f/db9b5e35c111d1829f0000e829fbfe/content.htm http://www.thespot4sap.com/articles/SAP_ABAP_Queries_FunctionalAreas_WithoutLogicalDB.asp Food for thought: LDBs and ABAP Objects
9 Comments
Bluesky
