Many Cards Versus One Card and a List Field

[Richard Gaskin]

Peter Alcibiades wrote:
> Maybe I don't understand the question (does happen!) but isn't the answer 
> something like this.
> 
> 1)  Once data storage gets serious, more than a few thousand records, Rev 
> alone is not what to do it in.  If you want to do the rest of the app in Rev, 
> you have to add a real database.  This means sqlite, mysql (if you need multi 
> user and networked), Valentina, whatever.
>   
> The issue is not one card versus many, the issue is tab delimited fields 
> versus real databases.  

True.  If you need a database, Rev has connections available for a wide 
variety of them, including SQLite, MySQL, Valentina, Oracle, and ODBC 
for everything else.

But as Mark Smith noted, you may be pleasantly surprised by what you can 
do with storing data in custom property sets.  One could use text files 
as well, but I tend to use properties so I can have metadata containing 
field names, types, and sizes in a separate property set from the data 
itself.  I regularly work with data sets from 100 to 50,000 records this 
way.

Using "repeat for each..." I can search at the rate of 98,000 records 
per second for a single-criterion search, and more than 34,000 records 
per second for a three-criteria search.  I can extract a single column 
at the rate of about a million records a second (for field 7; 1.4 
million for field 1), and return only unique values in that column at 
about three-quarter-million records per second.  And that's using a 
generalized (read "slower than is possible") method on a modest Mac.  On 
a top-of-the-line Wintel box I would imagine one can nearly double that.

For smaller data sets of about a thousand records or so, one can still 
use cards if desired.  I prefer the flexibility of separating code from 
presentation, but for quick-n-dirty solutions using cards can be convenient.

Being able to handle data up to 50,000 records in Rev alone is not bad, 
and having the connectivity to a variety of well-honed DBMS engines is 
even better.


> 2)  If data storage retrieval and reports is the primary or only need, its 
> incredibly much quicker to do that sort of thing to some level in Filemaker, 
> but it may not come for your OS and has other limitations.  But you do get 
> point and click relational database and report construction.  
> 
> This is a real issue about Rev + sqlite, but its also an issue about 
> alternatives to Rev + sqlite.

FileMaker is in a class by itself for ease of use, and I've seen a few 
projects done in Rev, even commercial ones, that might well have 
benefited from having been done with FMP instead.  It's a good tool, and 
if it does what a project needs it can be a very good choice.


> 3)  Even if you can live with tab delimited files for storage, getting reports 
> out of them in Rev is not much fun  So you have to add Quartam.  Or Perl or 
> Awk.  This too is much easier and quicker in FM.  But the same comment applies 
> to the alternatives to Rev. 

True, reporting in most 4GLs is done through commercial add-ons.  VB 
uses Crystal Reports, HyperCard used Reports Data Pro, and Rev uses Quartam.

That said, I've rolled my own reporting as needed, since my apps tend to 
have specialized needs, and they've been acceptable in both cost and 
performance.  Though I don't have the direct experience to say with 
certainty, I would venture to guess that rolling one's one reporting 
tools would be more costly in VB by at least a factor of two, and 
perhaps an order of magnitude in Java.


> Is there a gui package  (except the database packages with end user 
> pretensions like FM) that does data storage and retrieval and reporting much 
> better than Rev?  Most seem to be a lot worse.  Python for instance, I think 
> you have to use a real database for just about any storage.  Nothing is 
> perfect.
> 
> This is my own case:  15-20k records of sales during the fiscal year.  I 
> accumulate them (with some trepidation) into an external tab delimited text 
> file.  Then we need to go through and extract sales by product by month for 
> some 200+ items.  After a prolonged meditation on switch, if and repeat, and 
> the prospect of creating a 200 x 12 matrix of fields with each one 
> individually named and scripted, I broke out "Effective Awk Programming".  
> 
> Its like reaching for a plane, after trying to get a smooth finish with a 
> chisel.  But chisels have their uses too, and are often the right tool for 
> the job.  Don't try doing a mortise with a plane!
> 
> Well, please correct if this is not right.

I think you summed it up well.  If one needs a database, use a database. 
  If FMP, or even Bento (FileMaker Inc.'s new ultra-simple DB product) 
will do the trick, it'd be a shame not to use it.

And if one needs more flexibility with the UI than FileMaker 
accommodates, Rev can be used for tens of thousands of records natively 
or take advantage of its connectivity options for millions of records 
with any of its many DBMS engines.

-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com