From: "Richard Gaskin" <[EMAIL PROTECTED]>
Richard,
Everything in computing involves tradeoffs. The question of HC's storage
vs. Rev's is about paging:
Indeed. Makes sense.
With unusual care it was possible to have an unusually low number of
corrupted stacks in HC, but I never met a HyperCard developer who didn't
get a 5454 at least once.
I see. Interesting stuff. Thanks.
And for all that complexity and fragility, we still have a system whose
inventor made it clear more than once that he felt it was not a substitute
for a database (popular usage conflicting with his recommendation
notwithstanding).
LOL.
Raney took Aktinson's advice and built a system optimized to favor that
wisdom: if it's not a database, why create the fragile illusion that it
should be used as one, when there's a whole world of both performance
enhancement and developer control available.
Hmm. Makes sense. Though I can see how people would get the incorrect
impression, his recommendation or not. <g>
What is "real"?
OK. I was trying very hard to avoid that line, but it slipped in. <g>
A "database" could be seen more generically as a "data store", which may
help us appreciate the differences between a simple flat-file like HC and
a full-blown RDBMS, with its relationality, data types, and other features
which aren't part of the HC model.
Yep.
So think about it: if all you need is rows and columns, why not just use
rows and columns?
Agreed. Though in my own case - not committed yet - to a particular project
it's still pretty hefty a load to lift. Though custom prop's are something
I've been giving considerable thought to in relation to resolving it.
Why bother with the overhead of storing the data in fields on cards, when
you can easily parse item and line chunks of a single block of data so
very efficiently?
I have to say that I'd not come across something that makes handling arrays
so easy until I met Rev.
I've been using simple tab-delimited tables for a wide range of
application data for years, and have found it reasonably efficient for
data sets of up to 50,000 records, sometimes more. Even HC bogs down with
50,000 cards, and putting my records into HC fields and cards would bloat
the storage size by several MBs with all the unnecessary object overhead.
Yep. I can see that.
I started out writing these tables to text files, but inevitably I found I
wanted multiple tables, metadata, and a lot more. So instead I just
started tucking these tables into custom properties, and today my favorite
data file format is the stack file once again -- but rather than using
fields on a large number of cards, I store entire tables in a single
custom property, along with anything else I want in any other properties,
all easily and robustly accessible using native Rev commands.
This is where Chipp's point makes sense too. Seperation of the business
logic from the UI.
And think about it: since every Rev object has multiple property sets,
and a stack can have any number of cards, and cards can have groups,
etc. -- all this means you can have richly hierarchically-ordered data
sets using just custom properties. Hierarchies reflect much of the
world's taxonomy, and were not gracefully done with HC.
Oh I've been taking advantage of exactly that for some time now. :-)
So in brief, while Rev does ask developers to think about the needs of
their data more carefully, it also provides many rich ways to work with
that data very efficiently, all with native commands. For any project
with fewer than 50,000 records per table (probably about 80-90% of all
projects <g>), you may find you can do everything you need without a
single database connection. And as your needs grow, Rev provides those
too.
Yep. As I say my curiosity is to see how far the paradigm can be pushed.
As I suspected there are some limitations there that make huge datasets a
challenge, but certainly not insurmountable.
Thanks for your points (all of them) I really appreciate it!
Scott Kane
CD Too - Voice Overs Artist &Original Game and Royalty Free Multi-Media
Music
"There are two ways of being deceived. One is to believe that which is not
true. The other is to not believe that which is true." Søren Aabye
Kierkegaard
_______________________________________________
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
