Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Suggested Holiday DB

Status
Not open for further replies.

d0nny

IS-IT--Management
Dec 18, 2005
278
GB
Hi

I'm looking at designing a simple holiday/vacation request system online for my team at work.
Initially, I want to simply start by offering the normal user two options - a list of their holiday requests with a running total of holiday days left, and a holiday request form which when submitted will have a status of 'awaiting authorisation' and an email sent to the line manager. Obviously the line manager will then be able to login to set the status of the request to Approved or Declined (or any other status).

What I what is some advice on the DB structure.
I was thinking of a USERS table for users to login, a STATUS table, an AUTHORISORS table and then a REQUESTS table.

Does this sound about right?
Have I missed anything obvious?
 
yes, those tables sound fine, and you are well on your way

:)


okay, that wasn't entirely serious

it sounds like you are at the very early stages of application design

in my opinion you need to spend a lot of time on clarifying the business procedures you want to support

then design the application screens that will support them

and only then will you be ready to start the database design

r937.com | rudy.ca
 
Ah, yes, I understand.
I pretty much have done the business procedures. This is a simple replacement for our paper-based holiday request procedure. Everyone has a set amount of days to take and a spreadsheet-style form is completed and authorised for every request they put in. I want to do this exactly the same way but electronically.

As this is an internal app. to be used by a maximum of 20 people, the design doesn't need to be special, just usable. But I will model it on similar systems I've developed for Purchase Order requests and Timesheet entry system.

I am now at the stage were I want to starting the 'doing' and that includes putting a DB structure together.
Obviously, a lot more detail regarding the procedure would be required for anyone to comment on the DB structure, but given the high-level procedure described above, I just wondered if there were any glaring ommissions.
 
Well, yes, its along the same lines.
What I did with the old holiday app was strip out all the login/session code so I could simply load the app and try it out (which I was unable to do previously). What this allowed me to do was test the app to see if it was what I wanted, and it wasn't really. The main issue with this app is that it only allows one request per day across all users.
This may be the business process you want to adopt, but this should be more of a manual management decision post-request rather than a system decision.

So I've dropped that and I'm putting together my own holiday request app. It will be simple (cos I'm doing it ;-)) but it just needs to allow users to request holidays, the request is sent to the line manager who then authorises or denies the request. The status will then be updated and each user has a list of days requested/authorised/denied with a running total of days left.

Simple.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top