views:

185

answers:

2

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 )
+1  A: 

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.

Sean McMains
"Only load the Child records as they're needed. Using Get/Set accessors will allow you to load those up just-in-time" ... that would be ORM, and as far as I can tell Access will let me arrange such an approach but with no benefits as it is table-oriented. My attempt resulted in what I called RGORM, for Rube Goldberg ORM. Your insights? ....... "use a JOIN to retrieve all the child data at once" -- Yes, that's another step in dismantling RGORM, and a good catch. Kind of waiting on the resolution this question is all.
Smandoli
A: 

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

onedaywhen
No I haven't. Thank you for the link. I can't assess this immediately but I hope others who know the tech can chime in with a comment or vote.
Smandoli