Reflexive / recursive loads

Question

I read in the book <a href="http://www.sap-press.com/product.cfm?account=&product=H1941">Efficient SAP NetWeaver BI Implementation and Project Management</a> by Gary Nolan (appendix B.8.2, p. 357, BW Data Moel Review Checklist) that <i>reflexive</i> or <i>recursive loads</i> on transactional data should be avoided for performance reasons.
Does anyone have a better idea about the specific meaning of <i>reflexive</i> or <i>recursive</i> loads? Can you provide me an instance of recursive load?
Thanks, <a href="https://wiki.sdn.sap.com/wiki/display/profile/Davide+Cavallari">Davide</a>

Answer 1

I post the detailed explanation Gary Nolan - the author of the book - kindly sent me by email:
<i>Recursive loads are created by creating an export datasource from an infocube, thus creating an extractor from that cube.    The extractor is then loaded into the cube again.  This creates a cube loading to itself.    While this seems like an illogical setup, there are actually legitimate reasons to use it.  
You may want to loop through all the transaction records to check something or to update something.      For an easy example, perhaps you are tracking sales orders and have the salesperson stored in your infocube.   The salesperson to customer assignment is stored only in a ztable.    You read this ztable each time you load to assign the salesperson and put it in your InfoCube.    This works fine for all new sales orders, or those that have changed for the day because you get a delta.    Each delta record that comes through, you read the ztable and put the salesperson into the cube.  
If a salesperson assignment changes in the ztable all new records would take on the new salesperson.
But, what about the records that have been loaded in the past?    Those old sales orders are not going to come through on a delta, and thus would have the old (and incorrect) salesperson.  
In  order to fix this we could use a reflexive load to reload the infocube to itself and redetermine the salesperson for all records in the cube.   It has obvious performance implications because of the volume, but it does work.  
This should be considered the last resort for this type of data model.   Best to handle it via a master data table and use attributes of that...but sometimes this cannot be avoided.</i>