RE: [Dev-C++] student needs a little help

[Ioannis V. <no...@ya...>]

 <http://run.to/noicys> 
 -----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Saturday, February 16, 2002 9:58 PM
To: Dev-C++
Subject: Re: [Dev-C++] student needs a little help



The trick is to tailor your method of accessing the data to the type and
quantity of data and the access speeds needed. In the store example a
few thousand records wouldn't be unreasonable, and each record would be
on average no more than 30 bytes each (roughly). Say you did have 10000
record at 50 bytes (adding space for list implementation etc...), that's
500,000 bytes, in other words just less than 500kb (say half a meg). On
the scale of current memory usage that's pretty miniscule. There are
cases where it's impracticle to use memory and you have to use disk
stored systems, and there are a range of specialised algorithms for
dealing with them, but on the whole most developers would just use a
Database system for large scale data storage and retrieval. Another
factor to account for is the fact that most OS's have a virtual memory
ability, so in effect if you do load a large quantity of data into
memory it will be be automaticaly placed into a disk storage system, and
it saves you a lot of complex work on disk access algorithms.
 
Also by ordering a list of records into a predictable sequence you allow
for the use of special searching algorithms, as aposed to the basic
sequential search. What you use is yet again dependent upon scale and
speed requirement. However there are whole volumes dedicated to this one
subject alone so I won't go into detail here.
 
At a guess anything up to a couple of hundred megabytes is good for
memory storage (dependent upon the OS and target system in use), and
above that a more advanced data access system should be considered. Also
of note is that memory has somewhere on a scale of 1000 times quicker
access speeds than current disk technology.
 
After saying all that a linked list wouldn't be a perfect solution
because it's not the fasted model, a tree would be more suited, but they
all follow the same principal. Searching through 10000 records in a
linked list in memory wouldn't take more than a few seconds either (at a
guess).
 
Maybe you didn't want to know all that, but I think it's an interesting
subject.
 
Jason.
 

Of course i wanted to know. :) Well basically you didn't tell me
anything new than those i was imagining but it's an interesting topic
anyway. As for searching it depends what search you want, how the data
are sorted when they are stored e.t.c..
For example if you care searching by ID and the data are stored in ID
sequence, then you can implement very fast data location detection and
retrieval. So we agree on small database systems we can use linked
lists, e.t.c. and consider space/time trade offs. On large database
systems perhaps some tricks encapsulated in the list, e.g. caching/disk
retrieval combination.
 
Thanks for sharing your opinion.
 
 
 
Ioannis
 
* Ioannis Vranos
* Programming pages:  <http://www.noicys.d2g.com/>
http://www.noicys.d2g.com
* Alternative URL:  <http://run.to/noicys> http://run.to/noicys