You said it, O.

----------
> From: Olivia S. Anastasiadis <[log in to unmask]>
> To: [log in to unmask]
> Subject: Re: MUSEUM-L Digest - 17 Jul 1997 to 18 Jul 1997
> Date: Monday, July 21, 1997 8:03 PM
>
> Oh God you guys, when does this end?
>
> O
> Olivia S. Anastasiadis, Curator
> Richard Nixon Library & Birthplace
> 18001 Yorba Linda Boulevard
> Yorba Linda, CA  92886
> (714) 993-5075; fax (714) 528-0544; e-mail:  [log in to unmask]
>
> On Sat, 19 Jul 1997 09:16:10 -0500 Orycteropus afer <[log in to unmask]>
> writes:
> >>
> >>Date:    Fri, 18 Jul 1997 15:07:17 +0100
> >>From:    Philippa Tinsley <[log in to unmask]>
> >>Subject: dates 2000 or otherwise in automated systems
> >>
> >>In >>> Posting number 29182, dated 16 Jul 1997 00:00:0/
> >>Orycteropus afer <[log in to unmask]> wrote:
> >>
> >>Far too many automated systems define the fields
> >>used to record dates (acquisition dates, dates of manufacture, =
> >>conservation
> >>dates, movement dates, etc.) as what is called a "date" type field =
> >>internal
> >>to the database management system....This is almost always a BIG =
> >>mistake..
> >
> >Then Philippa responded:
> >>
> >>I'm sorry, but I absolutely have to disagree with this...
> >>
> >>I believe that the reason for having a computerised collection =
> >>management system is to help you more effectively and efficiently
> >manage =
> >>your collection.  To this end, it is important to utilise the
> >database's =
> >>searching facilities as well as possible.
> >>
> >>For example...
> >>I want to get a list of all objects donated to the museum in the (UK)
> >=
> >>tax year 1995/96
> >>
> >>If the field 'date acquired' is a date field, I can simply search for
> >=
> >>everything from 6/4/1995 to 5/4/1996 and the system will find them
> >all.
> >>
> >>However, if 'date acquired' is a character field (however
> >manipulated), =
> >>I have to search for the following sets of characters '4/1995', =
> >>'5/1995', '6/1995', '7/1995', '8/1995', '9/1995', '10/1995',
> >'11/1995', =
> >>'12/1995', '1/1996', '2/1996', '3/1996', '4/1996'.
> >>Then I have to go through all the objects found by this search and =
> >>discount those with the characters '1/4/1995', '2/4/1995',
> >'3/4/1995', =
> >>'4/4/1995', '5/4/1995', '6/4/1996' etc.
> >>If I also included some objects in my database just with the year of
> >=
> >>accession '1995', I'll have to make a separate search for these and =
> >>decide individually if I want to include them in my list.
> >>
> >>
> >>Philippa Tinsley
> >>
> >>[log in to unmask]
> >>[log in to unmask]
> >>
> >RESPONSE:
> >
> >If the masked date field is recorded in descending order of CCYY-MM-DD
> >then
> >the searching is as easy as it is with a date type field.  Obviously
> >if it's
> >recorded as DD-MM-CCYY, it's not.
> >
> >Additionally, in this age of open systems where you can purchase
> >off-the-shelf utilities and packages such as report generators and
> >work flow
> >systems that attach to standard SQL-based systems such as Access,
> >Oracle,
> >and SQL Server, you have to be careful to make sure that you don't
> >overly
> >program a field in a museum automation system.  For example, some
> >systems
> >store measurements in a "base" system of something say like
> >millimeters.
> >Then the system converts out to Imperial measurements (say inches) on
> >the
> >fly and displays them on the screen.  However, this capability isn't
> >likely
> >to be available in an off-the-shelf report generator that you want to
> >add to
> >your system and as a result you can't include Imperial measurements in
> >your
> >report because they don't actually exist in the database as a field
> >that the
> >report generator can incorporate into a report.
> >
> >Similary with dates, some systems have elaborate programs incorporated
> >into
> >their structure that concatenate multiple fields to create a display
> >field
> >(such as a numerical date format and a certainty field like ca. or
> >probably
> >and these certainty fields are often encoded).  This can't be easily
> >replicated with off-the-shelf systems so you cut yourself off from
> >everything but the hard programming in your system which means you
> >have to
> >then do more hard programming for reports, for the Internet, etc.
> >
> >So, the rule of thumb is to keep it simple in the database and avoid
> >using
> >macros and decoder tables.  This is particularly important as we go
> >into
> >intranet and Internet applications for public learning.
> >