[Ldsoss] Scout Tracking

[A. Rick Anderson]

Tom Welch wrote:
> I've used Dia in the past for Linux.  I've not used Umbrello but it 
> looks like it should do the trick just fine
I used Umbrello briefly once.  As I recall, it worked reasonably well 
for drawing, but I didn't care for its round-trip code-generation. 
Unless you are doing sequence diagrams, or generating code, my 
experience has been that CASE tools aren't worth the hassle.  Visio or 
Dia works just as well.

>     * As a general note:  If you want to allow for synchronization
>       between a local system and a remote system then all of your
>       primary keys should be in the form of a guid (I use varchar(32)). 
>       Most DB's have an auto-increment type for ints and these are used
>       as primary keys but you can't synchronize as easily .. especially
>       if you are allowing for a multi-user system because two keys could
>       get the same value.  If your is not to allow for synchronization
>       then I'd let the DB handle the auto-assigning of the primary key.
There was a previous link to GUID's and UUID's in an earlier discussion 
that pointed to Wikipedia.  Any system that wants to support 
synchronization should probably use some form of GUID.

>     * On the "address_table", what is the "date" field for?  Also do we
>       think that we will have multiple addresses for people and so need
>       to keep a separate table for them?  I agree if this is to be
>       expected then it would be more efficient to have the addresses in
>       a separate table.
With all the devorces, multiple addresses actually makes sense. 
However, to avoid burdening everyone with multiple addresses, you might 
define a set of "primary" address fields.

>     * What is the date field on the "phone_table" used for?  In fact,
>       all tables have a "date" field.  I'm not sure their purpose.
>     * On the "Emergency Contact" section, I can see that you intend to
>       have a small link table linking "boys" to their parents or other
>       contacts.  My comment here is that it may be a bit of "overkill"
>       to force the user to enter in all parents and other people that
>       act as emergency contact information into the DB.  What I mean is
>       that if I enter in a boy's information (address, phone number,
>       etc) I then have to enter in the same information for his parents
>       so that I can link the boy to the parent.  What you end up with is
>       two records with basically the same information.  It may be more
>       efficient to create a "family" table which would consist of the
>       last name of the family and then the address, phone numbers, etc. 
>       Then have a "family members" table which you enter in family
>       members (first name, birthdates, etc).  This way you are not
>       double or triple entering in the address.
To be PC, I'd suggest calling this a "Household" and you possible might 
want to define one or more "Head of Household".
>     * On the "authorization_table", I recommend that you lose the
>       "userid" and use the email address to verify and allow the user to
>       login. 
I hate it when sites do this.  You are presuming (a) a person's email is 
fixed for life, (b) that ISP's don't reissue email addresses.  Neither 
of these conditions are assured.  One of my original ISP's re-issued my 
email address to someone else within a few months of my dropping the 
account.  IMHO, email address should no more be used for a userid then a 
street address.

>     * On the Image and Picture tables, would it make more sense to store
>       the data in a blob in the DB instead of having a link to a file? 
>       Links are easily broken.
Also, file links tend to interfere with data portabilility.
> 
> Good start Oscar.
I'm not a fan of PHP, but databases are universal :-)  Also, going with 
a "web" application will usually facilitate a n-tier application 
approach, so even if the user stages it entirely on one box, the 
application will have been designed so that it can later be scaled. 
Putting a fat client on a web application is much easier then 
refactoring a desktop application or a client-server application.

-- 
A. Rick Anderson