Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!sun-barr!decwrl!ucbvax!pro-exchange.cts.com!rich
From: rich@pro-exchange.cts.com (Rich Sims)
Newsgroups: comp.sys.apple
Subject: Re: Market Research
Message-ID: <16039.apple.info-apple@pro-exchange>
Date: 16 Dec 89 06:23:55 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 81

In-Reply-To: message from done@pro-sol.cts.com (Don Elton)

I have no feel for what "most" users would think was more important, but for
myself, I'd go for the right database.  "Right" meaning that it has some
features I would find useful.  Some of the things I'd like are as follows:

(Gee, I never got to "design" a data-base before!)

1. Ability to merge data from other sources in a variety of formats, such as
fields delimited by tabs, returns, commas, etc.

2. A moderate "macro" ability during data entry, with the capability of either
using a 'standard' value or duplicating the previous entry, as desired.

3. Some way of linking long text entries to specific fields, either by direct
inclusion in the data file or as a separate file that's read when that field
is displayed -- sort of "semi-relational" I guess.  By "long" text entries, I
mean I'd like to be able to include a text document that's a few k long.

4.  I wouldn't find it particularly useful, but since this is a GS
application, I suppose some way of storing graphics would be mandatory for
most GS users.

5.  Ability to define specific fields to hold particular data types and
disallow invalid entries.  This should include an optional maximum entry
length.

6.  A field (or two) that are *automatically* updated with the current date
and time whenever any data in that particular record is changed or the record
is created (or data added).  This could be an optional field, not one that's
always created, although either way would be acceptable.

7.  Mouse usage should be optional, not required!

8.  Ability to create data entry "templates" that are accessible quickly and
easily by someone who's not necessarily familiar with all the "bells and
whistles" that the database provides.  This is to allow creation of the file
format and data fields, and then to allow anyone to easily enter the data from
a prompted or menu-type environment.

9.  It should recognize text and numeric data, and provide for treating either
type as the other.

10.  Once the data is in the records, I'd like to be able to manipulate it
almost without limitation, with the options of modifying the data and either
replacing the existing data with the result or creating a new field to hold
the result.

        This kind of thing should be programmable as a script or
        series of macros that can be called up at any point, so
        the sequence can be defined once and used over and over.

        Right along with the above, search/manipulation capability
        should include "pattern" or "expression" matching, rather
        than just being able to match literal data chunks.

11.  How about two variants?  One to be RAM based for small data files and one
to be disk based for larger amounts of data.  If only one were available, I'd
choose disk-based.  After all, we can already keep small stuff in AppleWorks.

12.  At the risk of drawing a lot of heat, how about designing the thing for
performance, not designing it to be useable on a one-floppy system.  (If it
still is useable that way, fine -- if not, well, that's life!)

13.  Report generation capabilities - along with all the normal stuff, it
should be capable of tabulating sub-groups of data as well as the entire
group, and preferably without any physical re-organization of the data file.
Let it do something simlar to this....

        Sort the output by last name, then first name, group it by
        ZIP code, and give me a count of the number of entries
        using each different phone number prefix.  (Not that I'd
        use that particular one, but similar stuff would be very
        useful to me.)

Oh yeah -- multiple data screens available, so they can be organized into
logical groups without cluttering up the display by trying to see everything
at once.

I can think of a dozen other features I'd like, but this is already too long,
so I'll give it up for now.