Many Cards Versus One Card and a List Field

[Richard Gaskin]

Hey Mikey -

Good to see you here.

Even though Bill Atkinson himself said that HyperCard isn't a database, 
I can understand the desire of those who've used it as one to use Rev 
similarly.

What made it possible to use HC that way was its "hint bits", a system 
for indexing field contents which is not only proprietary but patented 
as well.  Hint bits made it ultra-fast for obtaining data across the 
otherwise-complex structures that make up cards and fields.

So while we might want Rev to adopt something like this, in all fairness 
no other card-based system has ever done so, nor are they likely to in 
the future, for at least two reasons:

First, it's proprietary, and while it may be possible to recreate 
something similar from scratch it would be a fair amount of work, 
unlikely given:

Moreover, the rest of the world has moved on to separate content from 
presentation, and the Rev team seems well focused on those options.

In this thread we've outlined three distinct ways of managing data with Rev:

1. < 3,000 records:  cards work okay
2. < 50,000 records: delimited text stored in custom properties
3. > 50,000 records: true database engine (SQlite, MySQL, etc.)

If you were using RB, VB, Java, or just about any other system, the 
first two wouldn't even be options (well, you could store delimited text 
in a text file, but without the ease of working with metadata or Rev's 
chunk expressions).

Rev gives you all three, with a few limits on the first two.

And the latter two are reflective of pretty much how everyone in the 
world except HyperCarders work with data, providing a lot of flexibility 
and with the ease of Rev's chunk expressions and other scripting niceties.


FWIW, Rev does two other things HC never did:

As a RAM-based system, you have control over when it saves.  This allows 
you to implement true document behaviors, or write a simple automatic 
saving mechanism, whichever you choose.  HyperCard gave you no control 
over saving.

When saving, the entire file is written to disk in a single pass, rather 
than HC's paging from/to disk, which introduces a risk of file 
corruption that's nearly unknown in the Rev world (remember Error 
5454?).  Sure, the risk of corruption could be minimized in HC with 
regular compaction, but any paging system is inherently more prone to 
corruption than a non-paging one.

Extra bonus points: if power outage or other anomaly happens during 
save, the first thing the Rev engine does when saving is make a copy of 
the file as a backup, named the same as the file but preceded with "~" 
(e.g., "~mystack.rev").  So in the rare case where file corruption might 
occur, you have an automatic backup - just toss the bad copy, delete the 
"~" from the backup, and get back to work.


So in brief, Rev definitely works differently than HC, but I wouldn't 
necessarily think of that difference as being "broken".  HC had a number 
of conveniences unique to it, but in the modern world where most folks 
are accustomed to the flexibility of having content and presentation 
separated it doesn't seem likely the Rev team would be willing to devote 
the significant resources needed to replicate HC's hint bits.


For projects requiring a simpler approach than Rev offers, Bento may be 
worth looking at:
<http://www.filemaker.com/products/bento/>

It's a nifty tool, not nearly as flexible as Rev but it seems to do what 
it does well.

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