All this talk about DataBases
Scott Kane
scott at cdroo.com
Wed May 30 21:59:05 EDT 2007
From: "-= JB =-" <sundown at nwrain.net>
> One user said he was working with one million or more files so lets use
> that as an example. If I were to make a text file with one million card
> ids in item
> one and the user name in item two and then put it into a variable and
> perform a search for the id and
> retrieve the name:
Please keep in mind that my example is pretty extreme <g> and it's in text
file format because it is stored originally on a *nix system which handles
such volumes of text files far better than Windows does. Even still I
believe the original designer of the "text file database" in this instance
was not only "lame" but had rocks in his head.
> 1. What is the speed comparison to a database
A database with correctly optimized queries would handle most data lifting
in under the 1 second mark - more according to how much data. The example
above would probably still have a bit of a delay, but implemented as Rev
stacks and cards (for each record) it'd be at a minimum three to four
seconds if not a great deal more. This of course does not consider
multi-user issues, how much RAM is consumed and how well queries are
optimized which on some systems would make it difficult if not impossible to
operate using the stack/card paradigm. Even the design of the actual
database plays a crucial role in efficiency.
> 2. Is there a limit where this would not work or would be too slow in
> Revolution and why. If theR evolution search is too slow could a person
> write a faster search as an external.
The conclusion I've come to is that Rev can pretty much handle small data
sets - beyond the 10,000 record mark (and I suspect the definition of how
many and what type of fields are involved, what processes, calculations etc
are in place) pretty much is the limit in practical terms. For most small
systems this might be fine, for more complex or larger systems a system
(database) that is designed for the purpose is a better choice.
Scott
More information about the use-livecode
mailing list