what's it all about?
This is the start of a sequence of posts I expect to create that talk about the process I'm following to create a fairly trivial little application for use in our house... the Chore Assigner and Tracker (CAT, until I come up with a better name for it). This is a little application that's been growing in the back of my head for a while now. Many people would start this by designing the GUIs. I tend to think that's kinda asinine. It leads to applications where the main selling point is that the app emits smoke effects while it burns a cd (poorly burns a cd from the sounds of things).
Instead I think the first thing you need to do is look at the application and ask "What the fuck does this thing *DO*?" Well... it assigns chores to people, and tracks that they're completed. Some day it might have hooks into the firewall so that certain machines can't surf the web until their users have finished their chores. Sounds like a database to me. So step 1... schema design.
There are a couple enums in that, sched_process and usual_doer. Assume usual_doer is a standard UID, those are standardized across the lan, so no problem there. the scheduling process however is slightly different:
So that defines what a chore (task) is, now we need a mechanism to track their assignment and completion... another table:
I think this encapsulates all the information we need to store in the system. Of course I could be wrong, but that's what design/requirement reviews are for. I'll have one with the primary user on that schema shortly. (just did, neither of us see anything missing.)
I'll continue with the design of this application in a future post, I expect it to actually hit the code stage sometime soon.
Instead I think the first thing you need to do is look at the application and ask "What the fuck does this thing *DO*?" Well... it assigns chores to people, and tracks that they're completed. Some day it might have hooks into the firewall so that certain machines can't surf the web until their users have finished their chores. Sounds like a database to me. So step 1... schema design.
Type | Null | Name |
---|---|---|
int | PK | task_id |
str | NO | short_name |
str | NO | description |
int | NO | minutes |
int | NO | sched_process |
date | OK | offset |
int | OK | sched_order |
int | OK | usual_doer |
There are a couple enums in that, sched_process and usual_doer. Assume usual_doer is a standard UID, those are standardized across the lan, so no problem there. the scheduling process however is slightly different:
- disabled
- annual
- half
- quarterly
- monthly
- weekly
- daily
- daily+weekends
So that defines what a chore (task) is, now we need a mechanism to track their assignment and completion... another table:
Type | Null | Name |
---|---|---|
int | PK | work_id |
date | NO | in |
date | OK | out |
int | NO | task |
int | NO | doer |
str | OK | comment |
I think this encapsulates all the information we need to store in the system. Of course I could be wrong, but that's what design/requirement reviews are for. I'll have one with the primary user on that schema shortly. (just did, neither of us see anything missing.)
I'll continue with the design of this application in a future post, I expect it to actually hit the code stage sometime soon.
Labels: caatt, software engineering
1 Comments:
Wow, tables look like shit on here.
Post a Comment
<< Home