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
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
