[tirrigh-heralds] Client Tracking database

Thu Jun 7 20:47:52 PDT 2007

The birthdate was only required so Laurel could tell the difference 
between two submissions when the mundane names and SCA names match. 
Because of the mobility of our society now, address is not a reliable 
indicator of identity. I was working on Laurel staff when the SCA name 
were the same on name submissions (there was some uncertainty at the 
kingdom level as to whether or not the submission had been forwarded) 
and the mundane names were the same. While the addresses were different, 
that was not a good indicator that the people were different (for 
example, I've lived at five different addresses since 2002). When the 
birthdates were compared, they were different, so we were pretty sure 
the people were different.

While the field asks for birthdate, Laurel doesn't really care as long 
as the date that the submitter will use will always be the same.

Richenda

CAITRINA SABLE LOAT wrote:
> Greetings and YAY!  A project near and dear to me (hey I'm selfish).
>
> Looking over the tables it seems everything is covered.  I'm still undecided on the birthdate.  I first thought the reason it was required on the submission forms was due to the legal signature once required (if you're not legal how can you have a legal signature right?)  But the signature block was removed from the new submission forms so it really makes one wonder why do we need the person's date of birth?  The only reason I can come up with stems from having a father and brother who have the same names and bank at the same branch.  The only way their bank can tell them appart is by their birthdate... hence the reason my father goes by Senior now (should have thought of that before they named my brother).
>
> anyway, it's late, I'm mumbling and maybe a more experienced herald knows why we need the birthdate on submission forms?  A little off the client tracking database topic but if anything I'm curious.
>
> Caitrina
>
>   
>
> ------------------------------------------------------------------------
>
> Greetings unto the Tir Righ College of Heralds!
>
> This is a quick update on one of our projects, the client tracking 
> database.
>
> First, I decided that the goal of this project is only to track where 
> our clients are in the submissions process. It is not designed to 
> track all of the heraldic details of that process. That may be added 
> later, but we need to take small steps with this. Besides, that 
> information is more appropriate for OSCAR and we’re not trying to 
> duplicate those efforts.
>
> Accordingly, we have two tables, one to track information about the 
> person himself and one to track the information about the submission 
> itself.
>
> Those two tables are Client and Submission. Client has the following 
> fields:
>
> [ClientID] [int] IDENTITY (1, 1) NOT NULL , - The unique identifier of 
> the row in the table
>
> [SCAName] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT 
> NULL , - the SCAName of the person. This is required since we identify 
> people by name and branch
>
> [Branch] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL 
> , - the Branch of the person. This is required since we identify 
> people by name and branch
>
> [ModernName] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL 
> , - the modern name of the person.
>
> [Address] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , 
> - The street address of the person
>
> [Phone] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , - 
> the phone number of the person
>
> [Email] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , - 
> the email address of the person
>
> [Birthdate] [datetime] NULL , - the birthdate of the person
>
> [LastUpdate] [datetime] NOT NULL CONSTRAINT [DF_Client_LastUpdate] 
> DEFAULT (6 / 6 / 2007), - the date this row was last updated. Useful 
> for internal reasons
>
> Submission has the following fields
>
> [SubmissionID] [int] IDENTITY (1, 1) NOT NULL , - Unique identifier of 
> the submission
>
> [ClientID] [int] NOT NULL , - the person who is submitting heraldry. 
> Required
>
> [HeraldID] [int] NULL , - the consulting herald
>
> [Type] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL , 
> - the type of submission (Name, Device, Badge)
>
> [Notes] [varchar] (2000) COLLATE SQL_Latin1_General_CP1_CI_AS NULL , - 
> a notes field for information about the submission
>
> [StartDate] [datetime] NOT NULL , - the date the process started. This 
> is a sketchy date, but basically it’s when the client got serious 
> about wanting to register his heraldry. Required
>
> [KSubDate] [datetime] NULL , - the date the heraldry was submitted to 
> Kingdom
>
> [ILOIPubDate] [datetime] NULL , - the date the heraldry was published 
> in the ILOI
>
> [KRetDate] [datetime] NULL , - the date the heraldry was returned by 
> Kingdom for more work
>
> [KPassDate] [datetime] NULL , - the date the heraldry passed Kingdom
>
> [LOARPubDate] [datetime] NULL , - the date the heraldry was published 
> in the LOAR
>
> [LRetDate] [datetime] NULL , - the date the heraldry was returned by 
> Laurel
>
> [LPassDate] [datetime] NULL , - the date the heraldry was passed by 
> Laurel (in other words, it was registered)
>
> [LastUpdate] [datetime] NOT NULL CONSTRAINT [DF_Submission_LastUpdate] 
> DEFAULT (6 / 6 / 2007), - the date this row was last updated
>
> From a technical side, the computer can look at the dates of Start, 
> KSub, ILOI, et al and see what the latest date is. That’s the stage 
> the heraldry is in. From that information, we can make lists of who 
> has what where and keep on top of them.
>
> So does this look good? Are we missing anything? Are there any 
> superfluous fields?
>
> - Quentin Silver Yale
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Collegeofheralds mailing list
> Collegeofheralds at tirrigh.org
> http://mail.tirrigh.org/mailman/listinfo/collegeofheralds_tirrigh.org
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Collegeofheralds mailing list
> Collegeofheralds at tirrigh.org
> http://mail.tirrigh.org/mailman/listinfo/collegeofheralds_tirrigh.org
>   