Question

I'm using Access 2003 VBA to process recursive data for manufacturing BOMs. I built a class module to let my main tables have static scope. This seems to simplify recursion -- it sets me free from counting levels down and up again as I traverse a BOM. I'm not opening the same recordset redundantly; I'm filtering a lot instead.

After getting this underway I read about Object-Relation Modeling and decided to instance not a recordset, but a record. Then the fields of that record could be properties. After a lot of work and many thrills of victory that were mostly mistaken, I realized this approach has no benefits because Access is table-based.

My class modules still help as before. My question is about two alternative versions below. The first one uses two instances (Parent,Child). The second uses one and then reuses it. Obviously the first one is ORM-influenced.

Is there any reason to choose one of these over the other? Also, note the italics line at the end: If I don't need that (because I don't need more information on the Parent), does that change the answer? Can anyone help me with my thinking generally?

(Note that I close recordsets but not class instances. My understanding is that VBA instances close themselves and letting them do that is accepted practice. I seem to have taken pseudo-code to new levels of pseudo ... the goal is clarity, hope it works.)

    VERSION 1 
    Property Sub ReviewPart ( Parent_Part_ID )

    Get Parent_Part_ID
    Create instance of Class --> Get recordset
    Filter Class recordset ( Parent_Part_ID )
    Exploit Class recordset
    See if Parent_Part_ID has Childs
    If it does:
       Open recordset of Childs
       For each Child
         Get Child_Part_ID
         Create instance of Class --> Get recordset
         Filter Class recordset ( Child_Part_ID )
         Exploit Class recordset
         See if Child_Part_ID has Childs
         If it does:  
           Instance New ReviewPart ( Child_Part_ID )
         Otherwise:
         Nothing; Move On
       Next Child
       Close recordset of Childs
    Otherwise:
       Move On
    Exploit Class recordset ( still points to parent )
 
VERSION 2 Property Sub ReviewPart ( Parent_Part_ID ) Get Parent_Part_ID Create instance of Class --> Get recordset Filter Class recordset ( Parent_Part_ID ) Exploit Class recordset See if Parent_Part_ID has Childs If it does: Open recordset of Childs For each Child Get Child_Part_ID Create instance of Class --> Get recordset Filter Class recordset ( Child_Part_ID ) Exploit Class recordset See if Child_Part_ID has Childs If it does: Instance New ReviewPart ( Child_Part_ID ) Otherwise: Nothing; Move On Next Child Close recordset of Childs Otherwise: Move On Filter Class recordset ( Parent_Part_ID ) Exploit Class recordset ( still points to parent )
Was it helpful?

Solution

It seems that the former gives you better ease of use from the programmer's perspective, as one can simply start with the record you're interested in and easily root into associate records just by accessing properties of the record you started with.

On the other hand, the latter would appear to be more efficient, as it's not pessimistically loading every record that might be related to the current one.

A couple of potential optimizations to the first approach that might help it approach the efficiency of the second while maintaining ease-of-use:

  • Only load the Child records as they're needed. Using Get/Set accessors will allow you to load those up just-in-time, rather than all at once when the parent record is pulled from the DB.
  • Alternately, use a JOIN to retrieve all the child data at once as part of a single query. This would still give you all the data preloaded, but would reduce the number of queries you have to run to get it substantially.

Hope that's some help.

OTHER TIPS

Have you considered using the msdatashape provider and the SHAPE syntax to produce hierarchical ADO recordsets?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top