Re: Data Model

matthewdavis1980_at_hotmail.com wrote:
> topmind,
>
> Great post. After being out in production for a little while, some
> courts have requested extra types of staff, so it worked out pretty
> easily to just add another row to my stafftype table. They have also
> requested two staff of the same type for one court, because both staff
> members work the same position part time. A request by my boss has
> been made already to extend this data store to applications outside of
> the website. They want to use the staff part of it to be a centralized
> store for employee phone numbers and etc...so pretty much the rule of
> exactly only 6 types of staff for each court has been thrown out the
> window. The new rule is, you have any type of staff available to you,
> you pick and choose what you want. The above changes are exactly what
> I was expected to a certain degree, and it will be/was easy to pull
> them off, without having to hack and write an obscure work around.
>
> If I had kept this all in one table I would have been screwed.
>
> Thanks for your time and post,
>
> Matt

Matt,

Glad to hear it is working out okay.

Note that I prefer to use the word "roles" here rather than "type" because roles tend to be based on set-theory, where-as "types" are more hierarchical. A given person can potentially belong to many roles. However, "types" tend to assume or imply a one-and-only-one selection from a list or tree of options. One "has-a" role(s), but "is-a" type.

Just a linguistical pet-peve of mine.

Take Care,
-T- Received on Wed Apr 05 2006 - 03:42:04 CEST