Russell Martin wrote:
I realize I'm kinda late to the party on this topic, but I just want to
express my dismay at finding out that using stacks as databases is
prohibitively slow. That just seems bassackwards.
Some feel the opposite: binding the data to the UI makes one
representation of the data convenient (a detail view), but no other
representation will be as quick or convenient.
With all things in computing, performance is a matter of trade-offs.
There is no one-size-fits-all solution for any given problem once the
implications on all sides are taken into account.
Rather than enumerate them all and write one of my posts that's too
lengthy to read, let's see what we can do to make working with your data
as simple as possible with Rev. Hopefully by the time we're done you
might even be having fun. :)
How many records are you currently working with, and what is the
greatest number of records your system is likely to need?
How many tables does your system require, and how many fields in each?
Will the final system be used mostly by yourself, or will it be used by
others, perhaps within an organization or as a commercial product?
Will the system be used by one person at a time, or will it need to
support multiple concurrent users?
What is the purpose of the data? Is there an existing program which may
serve as an example for reference to get the gist of what you're building?
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
