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
_______________________________________________
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
