Re: baseball league db design

From: Bob Badour <bbadour_at_golden.net>
Date: Mon, 26 Jan 2004 15:25:32 -0500
Message-ID: <TdSdnYEqk9p_6ojdRVn-uw_at_golden.net>


"John O'Conner" <jsoconner_at_earthlink.net> wrote in message news:7ccfba12.0401261102.2da57bd5_at_posting.google.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
news:<NNGdnYwzX_c2fY7dRVn-hg_at_golden.net>...
>
> > Separating the addresses into a different table runs the risk that the
user
> > will overtype the address information when one person moves
automatically
> > moving everyone at the same address.
>
> Hmmm...hadn't thought of that. Good point. However, in this particular
> db, several siblings can play in the same league, and the league mgr
> mentioned that it would be nice to be able to avoid typing this
> information multiple times. If I keep an address with each sibling,
> we'd have to type in that information each time right?

Not necessarily. Regardless of how one represents the data, a user interface that allows the user to differentiate between wanting to update all of the entries at the same address or update one of the entries at that address or update some of the entries at that address is useful to the user.

For instance, when creating new records, one can leave the information typed in the previous record added or previously retrieved record and have the user change only what needs changing

When the user changes the address for a person at an address, the application can provide a list of people at the same address with check boxes for which of the other records to change.

etc.

Again, I must stress that a good data model will reflect all of the business rules so it is really not possible to give good and complete design advice on usenet. Received on Mon Jan 26 2004 - 21:25:32 CET

Original text of this message