jimbobob21 wrote:
>    I am using an access database to store the data, and am 
> wondering first, what the best way of grabbing and sending to 
> the database would be; and second, how/if I should store all 
> the info in memory, or what, I have a list of between 500-700 
> customers and am not sure if storing them in a collection, or 
> array is the best way to deal with the problem.

A binary search on an array is quite fast.  Faster than random access to a
collection.

There are problems with collections in VB.  Chris Sells has an excellent
example for C++ programmers on how to write collection classes that perform
well in VB, as well as a generic wrapper for non-optimized collections:
http://www.sellsbrothers.com/tools/

Arrays take longer to build from unsorted data than collections.  If you
need to add an element to the beginning of an array that already contains
11000 elements you will need to shift those elements into the next "slot"
which can be fairly time consuming.

For arrays of up to about 128 Kilobytes, using the CopyMemory api to shuffle
records about will provide adequate performance for sorting.

If the elements of your array are strings, variants, or object references,
then most of your data will be outside of the array (your array will just
contain pointers).

I use arrays for suburb drop-down lists.  It is very difficult for users to
look for a suburb name in a list of 11000 suburbs, and being able to enter a
postcode or just the first few letters of the suburb name can speed up data
entry  substantially.

The list of suburb names and postcodes is a good candidate for array-based
implementation because
* the data does not change frequently.
* the amount of data is not likely to grow substantially over the lifetime
of the application.
* I need fast access based on more than one index.

Assuming an average suburb name length of 16 characters, plus 4 characters
for the postcode (I'm in Australia), plus 4 bytes for an id field, plus 4
bytes for a pointer to the suburb name, plus 2 bytes for the string lengths,
each suburb record occupies 30 bytes in memory.

For 11000 suburbs, that's 322 Kilobytes.  By the time I've built a couple of
additional in-memory indexes, that just under 1 meg.

Even on my test PC which only has 32Mb RAM, the trade-off seems worth it (if
I really cared about 1 meg I'd ditch VB).

Arrays are a somewhat old-school approach, and I probably wouldn't do it
this way except that I've been coding VB since before ADO, and I find ADO
impractical when I want fast access with more than one index.

Most of what you could ever do with arrays can be done fairly easily with
disconnected recordsets, although I imagine the memory requirements would be
much the same.

I recall the term "in-memory database" being a bit of a buzzword in the late
90's.  The idea never really took off.  I suspect that the idea is somewhat
redundant on the server side because OS file caching on today's servers
would keep a lot of data in-memory anyway, without any help from the DBMS.

I think database usage has gotten more reliable since the advent of ADO and
the web, but the typical app now seems to require several more server
round-trips in order to enter a simple form.

This post is not meant to be a general endorsement of using arrays over
recordsets, merely a description of some of the implementation issues that I
have experienced.

You should think very carefully about relying too heavily on large arrays,
for the reasons Shawn has already outlined.

Adelle.



------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/k7folB/TM
--------------------------------------------------------------------~-> 


'// =======================================================
    Rules : http://ReliableAnswers.com/List/Rules.asp
    Home  : http://groups.yahoo.com/group/vbHelp/
    =======================================================
    Post  : [EMAIL PROTECTED]
    Join  : [EMAIL PROTECTED]
    Leave : [EMAIL PROTECTED]
'// =======================================================
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/vbhelp/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

Reply via email to