BusinessEntity Design Cancel The title field is required!

1. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   04 Jan 2019

   Link to this post

   Our Item table as many codes that point to other tables (one to one relationship). For example, we have a DeptNum that points to the Dept table (Dept.DeptNum). We actually have 19 codes that point to other tables.
   
   All we need is the Description field from these related tables so what I have done so far is add the Description from the related table to the eItem table and added the table as an additional source table. This does work and gives us what we need but I was wondering at what point it becomes a performance issue. It will make the source default query quite long with many outer joins. What is below only has 4 joins but if I do this for all there would be 19. Is it better to just add a calculated field to the temp table and populate in the BE ReceiveData?
   
   METHOD OVERRIDE PUBLIC CHARACTER SourceDefaultQuery (pcTable AS CHARACTER):
      
           @SourceDefaultQueryCaseBlock.
           CASE pcTable:
               WHEN "eItem":U THEN
                   RETURN "FOR EACH Item, FIRST UPC OF Item OUTER-JOIN, FIRST Dept OF Item OUTER-JOIN, FIRST LikeItem OF Item OUTER-JOIN, FIRST Mix OF Item OUTER-JOIN INDEXED-REPOSITION":U.
               WHEN "eTotals":U THEN
                   RETURN "FOR EACH Totals INDEXED-REPOSITION":U.
               WHEN "eHistoryTots":U THEN
                   RETURN "FOR EACH HistoryTots INDEXED-REPOSITION":U.
           END CASE .
          
       END METHOD.
2. Mike Fechner

   

   319 posts
   Registered:
   14 Sep 2016
   Answered

   04 Jan 2019 in reply to Roger Blanchard

   Link to this post

   A joined Data Source is usually the fastest. But there are limits ... I believe the REPOSITION-TO-ROW statement still has the limitation of 18 ROWID's as an argument. I expect the Prodataset Batching has a similar limitation. 
   
   The joined Data Source also supports filtering and sorting on those fields. 
   
   So multiple advantages. 
   
   Implementing a calculated field makes sense for fields that are calculated in another Business Entity (so a combined description field or a calculated price). The single-responsibility-principle prohibits to duplicate such logic. 
   
   When implementing calculated fields that access another Business Entity, I typically do that in a FOR EACH grouped-by the relevant key field to do the call to that other Business Entity only once for a given key value. 
3. Roger Blanchard

   

   381 posts
   Registered:
   29 Jun 2018
   04 Jan 2019 in reply to Mike Fechner

   Link to this post

   Thanks Mike. we will test this out.
   
   Happy new Year!!