roskill@cs.umass.edu (03/02/90)
Hello,
I have a database problem I have been considering putting into
Supercard. I tried doing it in Hypercard and it failed so badly
that I actually looked at dBase (mac version). Anyway, here's
the problem, and if people could comment on whether it is
pratical to do it in Supercard, I would be very appreciative.
ArtBase
-------
ArtBase is intended to store information and documents. It uses
the metphor of an index card, as that is the way it is currently
set up in the real world.
Each card deals with an individual document. On each card, there
is:
1. A date (the date of the document)
2. A brief description that will contain key words (see below)
3. The actual document (anywhere from 1 to 15 pages)
4. A "Commentry" section. This section contains key words
of other documents (the keywords are stored in the "Brief
Description"). The idea here is that the user should be
able to double click on one of these key words and have the
computer search all other cards for these key words.
5. A bibliography reference for the document.
There must also be a bibliography for the whole database.
Ok...now the problems:
1. I am expecting there to be 3000+ of these cards. Supercard
already seems slow, but is it even remotely feasible to do this?
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.
Can anyone comment on this problem?
Damian
|----------------------------------------------------------------|
|"Party For Your Right To Fight" | "Welcome to the Terrordome!"|
| Damian Roskill | |
| Roskill@cs.umass.edu | |
|----------------------------------------------------------------|chuq@Apple.COM (Chuq Von Rospach) (03/02/90)
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
roskill@cs.umass.edu (03/06/90)
Obviously I have a few things to clarify about my database design project. B-] In article <39106@apple.Apple.COM>, chuq@Apple.COM (Chuq Von Rospach) writes... >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? The document are not text-only. They have to be able to have the normal Mac typefacing commands (i.e. bold/underline/etc.). The size of the document could be 90,000+ or less. It would be nice if the documents were searchable. >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. Ok...so let's say that I can run Hypercard and MS Word at the same time, and I want it to function like this: for each card, there is an associated file. If the user click on a button (that says something like "Go to Text"), is it possible to force MS Word (4.0) to open that document and switch to MS Word? >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. > I agree that Hypercard is not powerful enough to do this and grow. But does anyone know of another solution (i.e. another database program that can do this kind of stuff)? I also wanted to thank everyone again for helping me out with this. Damian Roskill |----------------------------------------------------------------| |"Party For Your Right To Fight" | "Welcome to the Terrordome!"| | Damian Roskill | | | Roskill@cs.umass.edu | | |----------------------------------------------------------------|