DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: Analyzing an example in Rockford Lhotka book's "VB6 Business Objects"

  1. #1
    Antonio Paglia Guest

    Analyzing an example in Rockford Lhotka book's "VB6 Business Objects"

    + VideoPersist
    + TapesPersist
    + TapePersist

    Analyzing the Fetch method of TapesPersist object descripted in page 480 of
    his book VB6 Business Objects. It creates a recordset containing only the
    TapeID. Then, makes a loop invoking the Fetch method of the TapePersist
    object for each obtained TapeID.
    The TapePersist Fetch method creates a new recordset containing all the
    information of a Tape .

    There are no doubts that this way encapsulates the data of TapePersist. In
    fact, the TapesPersist object does not know the fields of each TapePersist
    object .We have a very elegant and simple solution.

    Now, imaginate the following scenario. The collection Tapes of Video object
    contains 50 Tape objects. In addition, the table TAPES of the database
    contains 20.000 record.

    It is not more efficient that the fetch of the TapesPersist object obtains
    in an only access to the database, all the information of each Tape instead
    of (50 + 1) Dataccess ?



    --
    Antonio Paglia
    e-mail:
    - apaglia@infovia.com.ar
    - antoniopaglia@hotmail.com








  2. #2
    Colin McGuigan Guest

    Re: Analyzing an example in Rockford Lhotka book's "VB6 Business Objects"

    Antonio Paglia <apaglia@infovia.com.ar> wrote in message
    news:39d0992c@news.devx.com...
    > It is not more efficient that the fetch of the TapesPersist object obtains
    > in an only access to the database, all the information of each Tape

    instead
    > of (50 + 1) Dataccess ?


    Yes, it is more efficient to obtain it all in one go.

    It's also more efficient (machine-code-wise, not time-wise) to write
    everything in assembler.

    Especially when dealing with OO, most everything's a tradeoff between
    machine-efficiency and programmer-efficiency. Sometimes one needs to be
    strengthened at the expense of the other. IMHO, you should run the code the
    way that seems most elegant (ie, the one that would be easiest to change
    down the road), and see if there's a speed problem, first. If, and only if,
    there's a speed problem should you worry about improving the speed.


    --
    Colin McGuigan




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center