Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!chuq
From: chuq@Apple.COM (Chuq Von Rospach)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: Designing a database
Message-ID: <39106@apple.Apple.COM>
Date: 1 Mar 90 20:52:28 GMT
References: <10833@dime.cs.umass.edu>
Distribution: usa
Organization: Fictional Reality: where your dreams can come true
Lines: 54

roskill@cs.umass.edu writes:

[Caveat: I'm not very familiar with Supercard, so I'm assuming for the
 purpose of this discussion that it's pretty much like Hypercard with
 enhancements. People are welcome to clarify differences where I screw
 up...]

Based on what you're asking for, I wouldn't touch either HC or SuperCard.
Not just the size of the thing (3000 records), but some of the requirements
are going to be beyond the capabilities of a hypercard-like program. I
haven't read anything about Supercard that leads me to believe it's that
much stronger in database functions than HC.

>     3. The actual document (anywhere from 1 to 15 pages)

Are they text-only documents? How large? 15 pages can be as much as about
70,000 characters, which would be difficult to impossible to wedge into a
single field. Do the documents need to be searchable inside the document?

A better approach would be (unless the text needs to be searchable) to keep
the document separate and keep it in some well-known place maintained by the
stack. See the technotes stack as one example. If the documents are non-text
(word or whatever) this'll be pretty much a necessity. Some databases have a
concept of a 'blob' datatype, which is basically a binary piece of stuff the
database keeps and doesn't muck with.

The way I'd handle it is with an 'import [or export] document' button that
either gets or retrieves the document from the holding folder, or, if
possible, store it inside the database structure as a blob or a pseudo-blob.
Storing the text on the card is likely to make searching a lot more
difficult and probably slower.

>2. Printing: the printing of reports must be extensive, and include
>   multiple fonts/typefaces/font settings (bold,underline,etc.) in
>   a single field as well as being able to print different reports/
>   formats.

I think the printing aspects will also kill you. HC just can't cut printing
yet.

This sounds like a couple of databases I've been playing with -- they're
complex enough that I think putting them in a real database is justified,
rather than using an environment like HC and constantly bumping into the
edges. I'd rather start in an environment is a little too powerful for what
I"m doing and expect to grow into it than start with something that's not
quite powerful enough and hack it to fit, because you end up spending most
of your time fighting it to make it work.


-- 

Chuq Von Rospach   <+>   chuq@apple.com   <+>   [This is myself speaking]

All spirits are enslaved which serve things evil -- Shelley