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.
>
|
