Message-Id: <9403032219.AA23582@us2rmc.bb.dec.com>
Date: Thu, 3 Mar 94 17:19:11 EST
From: touche!  03-Mar-1994 1707 <groff@epee.enet.dec.com>
To: dagoura@MIT.EDU
Cc: groff@epee.enet.dec.com
Apparently-To: dagoura@mit.edu
Subject: Re: more fields 

~IIIIAGGG!  Miss-communication.  All I want gone is "interests",
~because is is impossible to sort meaningfully by that kind of field.

Ummm, since I came up with the Rolls-Etherial idea (and did it for a short
time and then handed it to Justin when Alt.SCA started...), I disagree.  We can
agree to disagree here.  The "checklist" concept is the "best" way to handle
it, but if we recommend "keyword only" and let it go at that... I will one
day may a list of keywords... and compress out the "different" names... its not
hard.  This is a good way to get a list of keywords :-)

Really...  DB maintenance tools, query tools, and simple programming when you
have a POWERFULL database can help a lot!

BTW: I need to add one more field: 

	KINGDOM:

to the list.  We may have "easterners status mentus est" who live in
Ansteorra...


~The only solution is to make an explicit menu ("circle all that
~apply") and I really don't feel like trying to do that.

see above.  Its not the "only" solution

~In addition: have you ever scanned through the Rolls Etherial?  People
~put down whatever comes to mind at the moment; you'll see things by
~people's names which you know they never did in the Society, or which
~amused them for all of a 2 week period.

see above... I started it.

~I'm arguing that it's *not* information.  It doesn't belong in a
~database. It's just not worth it.

I argue we need this field.  It doesn't hurt to leave it in.

~I am keeping an eye on the longterm, but on a fundamental level, this
~is a highly radical, political act.  

That is not why I am doing this.  This is a fundamentally important project for
the East and the Society (not Inc) as a whole.  This is a central place where
contact information is kept.  It has privacy fields to allow people to use it
for lookup.  I hope to put a "key" into allowing the person to change it
themselves... etc.  I see this as a LONG TERM benificial project... that just
happens to provide political advantage in this fight.

[think of this as the arguement: guns don't kill people, people kill people. 
 Guns can be very usefull tools.  

 The BOD believes that Information kills Corporations, not Disgruntalled
 Customers kill corporations.  Our stance is that Information keeps customers
 happy and well armed in case of attack by corporations that go rogue.]

~how old are you? 

hmmm good idea, maybe that would be a good thing to get now.

~>   SCA Member # (if a member):				[R]     {int}
~Required #?? How will it cope with an empty string?

my mistake

~>   Mundane Middle Initial:	[R]     {char[3]}
~
~Again, what about empty strings?


Empty strings are detected and rejected for "required" fields and sent back to
the submitter with an error message.  In this case, middle initial should be
optional.

~>  History:		[A]	{segmented string}
~> 	containing:
~> 	 Date:		[A]	{Date}
~> 	 Update_By:	[A]	{char[80]}
~> 	 Type of change	[A]	{keyword}
~Excellent.  That works.  Do we want a "data taken by" field?  This
~would be to record which census worker took the information on hard
~copy.  

That is exactly what is in the History field.  That is a segmented string that
is updated each time the row is changed.  "Add" is a change.  It will grab the
EMAIL address and the date.  It will fill in the type of change (Add, Change)
to the list.  Delete is something we have to consider "how" to do.  I am
considering an operation which moves the data from the main table to a
"deletion's" table.  Delete would have to have a comment field to add to the
history list.  Final purge of the DB would be a manual operation.

-Danulf