All this talk about DataBases

[Scott Kane]

From: "Richard Gaskin" <ambassador at fourthworld.com>

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