Many Cards Versus One Card and a List Field

[Richard Gaskin]

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