Skip to Content
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. image  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.         image 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 
To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Former Member
    Hi Srivijaya:

    Nice blog…I have only used LDB’s for HR Programming, but maybe I need to find more applications for it.

    Greetings,

    Blag.

    (0) 
    1. Former Member
      hi Sri Vijaya,

      Its a nice blog.The content of the blog is presented in a simple and lucid manner.It highlights the advantages and as well explains it with nice examples.

      Good Job…keep it up.

      Regards,
      Saujanya

      (0) 
  2. David Halitsky
    Srivijaya –

    LDB’s are dead as a door-nail because the majority of influential SAP developers appear to be more interested in market-drivers than in improving SAP’s back-end stuff.

    Plus, of course, you have the fact that the locus of development on data-retrieval has moved to BI and accelerated BI because native relational DB’s have proven themselves over and over again to suck when anyone tries to use them above the level of the “mom and pop” shops that bought Larry his yacht.

    The failure of SAP to develop LDB’s further (beyond the valley of report-writer and painter) is just another example of the point I just made here in this Coffee Corner thread:

    Ouch! Ugh! Never seen something as ugly and embarassing as this!

    I mean – isn’t it ridiculous that we already have full external debugging in WDA while the plain old ABAP debugger doesn’t always play nice with BADI method code ?

    Well – since it’s ABAP month, maybe we need to organize a chapter of the SPCA called SPCAP:

    Society for the Prevention of Cruelty to ABAP Programmers …

    regards
    djh

    (0) 
    1. LDBs are still my tool of choice for HR programming.  It is so efficient for getting an HR Report up and running.  Standard selections are taken care of, security is taken care of.  You can manipulate the selection screen with Report Categories.

      Until somebody provides me a more useful and efficent too for backend HR Reports, I will always use them.

      Chris H.

      (0) 
    2. Former Member Post author
      Hello DJH ,
      Nice to see ur comments. I must admit that , i have never worked with the latest technologies sofar and iwas mainly developing backend stuff and thats too for FICO-TR. In our area , the reporting is complex. I mean there several hundreds of keyfigures which come from more than 200 tables and involve complex maths and analytics. Infact, i was told that customers were extremely unhappy with TR Reporting 5 years back and now with LDB’s they seems to be fine. And reg. BI content , we are still developing BI Content i.e. still in an early stage. Mainly LDB’s seems to be used for quick reporting using SAP Query.
      I would like to know , what would be  an alternative for a module like Treasury(TR)? 
      What are various reporting tools which could make complex reporting quick & easy ?

      thanks ,
      Sri

      (0) 
  3. Former Member
    Nice Blog.
         I definitely use LDB for HR reports/programs for the reasons mentioned above.
         I’ve also used LDBs for Fixed Assets (ADA) and Project Systems (PSJ) due to improved performance as well as understanding complex table relationships/hierarchies for these objects.

    Mike Vondran, eBay

    (0) 

Leave a Reply