|
|
You're in the
sql server programming
group:DB Design Question.
sql server programming:
I am trying to come up with a good db design for time tracking an employee's time on one of the client projects that I am working on. The background is as follows: 1). An Employee can work on administrative tasks and also some special projects. 2). An Employee can also work on customer issues. 3). If an employee is on a vacation he will not work neither on any projects or customer issues. The tables I have designed so far look like this: Table 1: Admin --------- AdminID AdminDesc The Admin Desc can include: Vacation,General tasks,Sick,Training etc. Example data AdminID Desc ------ ----- 1 Vacation 2 General 3 Sick 4 Training 5 Time Tracking Table 2: Projects --------- ProjectID ProjectDesc The Project Desc can include: ProjectA, ProjectB, ProjectC etc. Example data ProjectID ProjectDesc ------ ----------- 1 ProjectA 2 ProjectB 3 ProjectC 4 ProjectD 5 ProjectE Table 3: Customers --------- CustomerID Name ProblemType The Customer Name can include: Customer1, Customer2, Customer3 etc. The ProblemTypecan include: DR, Performance, Querytuning etc. Example data CustomerID Name ProblemType ------ ----- 1 Customer1 Disaster Recovery 2 Customer1 Performance 3 Customer2 Backup issue 4 Customer3 Query Tuning Finally My EmployeeTable for Time tracking would be: Table 4: Employee --------- EmployeeID EmployeeName AdminID ProjectID CustomerID Timespentinhrs Example Data: EmployeeID EmployeeName AdminID ProjectID CustomerID Timespentinhrs 10 Rob 4 NULL NULL 2 10 Rob NULL 2 NULL 10 10 Rob NULL NULL 1 25 10 Rob NULL NULL 1 10 10 Rob NULL NULL 2 3 The total time spent by an employee in the above case would be :50 I need to know if this can be designed in a better way? Also How do I track the problemtype for an employee for a customer? Also is it a bad idea to include the problemtype for the customer in the Employee Table? please give your thoughts and suggestions. Thanks Ankith.
Take these suggestions for what they are - the ramblings of a bored
programmer avoiding the unrewarding tasks on todays agenda. I may be completely off the mark but your design seems a little circular and denormalized to me. Q1. Why separate admin from projects - Combine these into one table -- their column definitions are identical - the ID can be assigned to the timesheet. Consider adding a column to define the "Type". If you really want to go crazy - Type can be a domain table all to itself and the type column would be a number. I didn't do that here but you could if your type list was determined to be large. ProjectID ProjectDesc Type ------ ----------- ----------- 1 ProjectA Task 2 Vacation Admin 3 ProjectC Task Customers - Consider NOT including a Problem type in a "Customer" table. To do so would result in multiple rows per customer. A table named customers should define a customer. Customer CustomerCode Name Address ... 13458 Sea Watch Int'l Task TaskID Description 80 Open - Multiple Issues 90 Connectivity 91 Disaster Recovery 92 Performance Tuning Space and speed are probably not an issue but integers take less space than names and are much faster to join on. You can create another table for when a customer engages services for a specific project. This table would repeat the customer ID much like your Customers table. Let's call it Engagement EngagementID EngagementName CustomerCode ... 123 Connection Prob. 13458 Your Employee Table for time tracking - Consider renaming to something like EmployeeHours or Timesheet EmpID EngagementID ActivityDate ActivityFrom ActivityTo TimeSpent TaskID 789 123 9/28/2006 NULL NULL 2 90 NOTE: Depending on the design of your interface, you can inforce input of activity time from and to NOTE: Including the TaskID at the timesheet level allows much more flexibility. What if a customer want you to do 10 things. Are you going to set up 10 rows in the table that you named "customers" then have your employees pick from the list. These lists would grow considerably over time and they would require a lot of time on the part of team leaders to enter the projects commissioned by customers. This way you create one engatement and the emp. can charge multiple tasks to it. If you want to limit the tasks that are available for an engagment, use another table "EngagementTasks" with the engagmentID and taskID. Employee EmpID EmpName EmpAddress (you could even add some calculated fields like remaining vacation or sicktimetaken) 789 Bill Chicago 8 40 [quoted text, click to view] Ankith wrote:
> Hi Everyone: > > I am trying to come up with a good db design for time tracking an employee's > time on one of the client projects that I am working on. The background is > as follows: > > 1). An Employee can work on administrative tasks and also some special > projects. > 2). An Employee can also work on customer issues. > 3). If an employee is on a vacation he will not work neither on any projects > or customer issues. > > The tables I have designed so far look like this: > > Table 1: > > Admin > --------- > AdminID > AdminDesc > > The Admin Desc can include: Vacation,General tasks,Sick,Training etc. > > Example data > > AdminID Desc > ------ ----- > 1 Vacation > 2 General > 3 Sick > 4 Training > 5 Time Tracking > > Table 2: > Projects > --------- > ProjectID > ProjectDesc > > The Project Desc can include: ProjectA, ProjectB, ProjectC etc. > > Example data > > ProjectID ProjectDesc > ------ ----------- > 1 ProjectA > 2 ProjectB > 3 ProjectC > 4 ProjectD > 5 ProjectE > > Table 3: > > Customers > --------- > CustomerID > Name > ProblemType > > The Customer Name can include: Customer1, Customer2, Customer3 etc. > The ProblemTypecan include: DR, Performance, Querytuning etc. > > Example data > > CustomerID Name ProblemType > ------ ----- > 1 Customer1 Disaster Recovery > 2 Customer1 Performance > 3 Customer2 Backup issue > 4 Customer3 Query Tuning > > Finally My EmployeeTable for Time tracking would be: > > Table 4: > > Employee > --------- > EmployeeID > EmployeeName > AdminID > ProjectID > CustomerID > Timespentinhrs > > Example Data: > > EmployeeID EmployeeName AdminID ProjectID CustomerID Timespentinhrs > 10 Rob 4 NULL NULL 2 > 10 Rob NULL 2 NULL 10 > 10 Rob NULL NULL 1 25 > 10 Rob NULL NULL 1 10 > 10 Rob NULL NULL 2 3 > > The total time spent by an employee > in the above case would be :50 > > I need to know if this can be designed in a better way? Also How do I track > the problemtype for an employee for a customer? Also is it a bad idea to > include the problemtype for the customer in the Employee Table? > > please give your thoughts and suggestions. > > Thanks > > Ankith.
Thanks for the suggestions. However I still have two questions.
1). How can I track the time spent on a project for an employee. You dont have the time for specific project in the timesheet table. 2). How can i tie the task spent for a customer?. I think the timesheet table might need one another column. Is that right?. Thx [quoted text, click to view] "wbpelen@yahoo.com" wrote:
> Take these suggestions for what they are - the ramblings of a bored > programmer avoiding the unrewarding tasks on todays agenda. > > I may be completely off the mark but your design seems a little > circular and denormalized to me. > > Q1. Why separate admin from projects - Combine these into one table -- > their column definitions are identical - the ID can be assigned to the > timesheet. Consider adding a column to define the "Type". If you > really want to go crazy - Type can be a domain table all to itself and > the type column would be a number. I didn't do that here but you could > if your type list was determined to be large. > > ProjectID ProjectDesc Type > ------ ----------- ----------- > 1 ProjectA Task > 2 Vacation Admin > 3 ProjectC Task > > Customers - Consider NOT including a Problem type in a "Customer" > table. To do so would result in multiple rows per customer. A table > named customers should define a customer. > Customer > CustomerCode Name Address ... > 13458 Sea Watch Int'l > > Task > TaskID Description > 80 Open - Multiple Issues > 90 Connectivity > 91 Disaster Recovery > 92 Performance Tuning > > Space and speed are probably not an issue but integers take less space > than names and are much faster to join on. > > You can create another table for when a customer engages services for a > specific project. This table would repeat the customer ID much like > your Customers table. Let's call it Engagement > EngagementID EngagementName CustomerCode ... > 123 Connection Prob. 13458 > > Your Employee Table for time tracking - Consider renaming to something > like EmployeeHours or Timesheet > EmpID EngagementID ActivityDate ActivityFrom ActivityTo > TimeSpent TaskID > 789 123 9/28/2006 NULL NULL > 2 90 > > NOTE: Depending on the design of your interface, you can inforce input > of activity time from and to > NOTE: Including the TaskID at the timesheet level allows much more > flexibility. What if a customer want you to do 10 things. Are you > going to set up 10 rows in the table that you named "customers" then > have your employees pick from the list. These lists would grow > considerably over time and they would require a lot of time on the part > of team leaders to enter the projects commissioned by customers. This > way you create one engatement and the emp. can charge multiple tasks to > it. If you want to limit the tasks that are available for an > engagment, use another table "EngagementTasks" with the engagmentID and > taskID. > > Employee > EmpID EmpName EmpAddress (you could even add some calculated > fields like remaining vacation or sicktimetaken) > 789 Bill Chicago 8 40 > > > Ankith wrote: > > Hi Everyone: > > > > I am trying to come up with a good db design for time tracking an employee's > > time on one of the client projects that I am working on. The background is > > as follows: > > > > 1). An Employee can work on administrative tasks and also some special > > projects. > > 2). An Employee can also work on customer issues. > > 3). If an employee is on a vacation he will not work neither on any projects > > or customer issues. > > > > The tables I have designed so far look like this: > > > > Table 1: > > > > Admin > > --------- > > AdminID > > AdminDesc > > > > The Admin Desc can include: Vacation,General tasks,Sick,Training etc. > > > > Example data > > > > AdminID Desc > > ------ ----- > > 1 Vacation > > 2 General > > 3 Sick > > 4 Training > > 5 Time Tracking > > > > Table 2: > > Projects > > --------- > > ProjectID > > ProjectDesc > > > > The Project Desc can include: ProjectA, ProjectB, ProjectC etc. > > > > Example data > > > > ProjectID ProjectDesc > > ------ ----------- > > 1 ProjectA > > 2 ProjectB > > 3 ProjectC > > 4 ProjectD > > 5 ProjectE > > > > Table 3: > > > > Customers > > --------- > > CustomerID > > Name > > ProblemType > > > > The Customer Name can include: Customer1, Customer2, Customer3 etc. > > The ProblemTypecan include: DR, Performance, Querytuning etc. > > > > Example data > > > > CustomerID Name ProblemType > > ------ ----- > > 1 Customer1 Disaster Recovery > > 2 Customer1 Performance > > 3 Customer2 Backup issue > > 4 Customer3 Query Tuning > > > > Finally My EmployeeTable for Time tracking would be: > > > > Table 4: > > > > Employee > > --------- > > EmployeeID > > EmployeeName > > AdminID > > ProjectID > > CustomerID > > Timespentinhrs > > > > Example Data: > > > > EmployeeID EmployeeName AdminID ProjectID CustomerID Timespentinhrs > > 10 Rob 4 NULL NULL 2 > > 10 Rob NULL 2 NULL 10 > > 10 Rob NULL NULL 1 25 > > 10 Rob NULL NULL 1 10 > > 10 Rob NULL NULL 2 3 > > > > The total time spent by an employee > > in the above case would be :50 > > > > I need to know if this can be designed in a better way? Also How do I track > > the problemtype for an employee for a customer? Also is it a bad idea to > > include the problemtype for the customer in the Employee Table? > > > > please give your thoughts and suggestions. > > > > Thanks > > > > Ankith. >
The suggestions were not meant to be the entire solution. I would
certainly and columns to every one of the tables making sure that the data is repeated as little as possible and that it all joins back so that data can be broken down or joined to report on. As to your questions: Can I track time spent on a project for an employee/for a customer? If I understand the question - yes. The EngID on timesheet ties back to the engagement table which can yield time spent on a project by one or all employees. The customer ID is also on the Engagement table so this same join yields time spent by customer. Also having the TaskID on the Timesheet table allows for additional breakdowns of the data. Proper use of the sum function and grouping of data should give you the results you are looking for. [quoted text, click to view] Ankith wrote:
> Thanks for the suggestions. However I still have two questions. > > 1). How can I track the time spent on a project for an employee. You dont have > the time for specific project in the timesheet table. > 2). How can i tie the task spent for a customer?. > > I think the timesheet table might need one another column. Is that right?. > > Thx > > > "wbpelen@yahoo.com" wrote: > > > Take these suggestions for what they are - the ramblings of a bored > > programmer avoiding the unrewarding tasks on todays agenda. > > > > I may be completely off the mark but your design seems a little > > circular and denormalized to me. > > > > Q1. Why separate admin from projects - Combine these into one table -- > > their column definitions are identical - the ID can be assigned to the > > timesheet. Consider adding a column to define the "Type". If you > > really want to go crazy - Type can be a domain table all to itself and > > the type column would be a number. I didn't do that here but you could > > if your type list was determined to be large. > > > > ProjectID ProjectDesc Type > > ------ ----------- ----------- > > 1 ProjectA Task > > 2 Vacation Admin > > 3 ProjectC Task > > > > Customers - Consider NOT including a Problem type in a "Customer" > > table. To do so would result in multiple rows per customer. A table > > named customers should define a customer. > > Customer > > CustomerCode Name Address ... > > 13458 Sea Watch Int'l > > > > Task > > TaskID Description > > 80 Open - Multiple Issues > > 90 Connectivity > > 91 Disaster Recovery > > 92 Performance Tuning > > > > Space and speed are probably not an issue but integers take less space > > than names and are much faster to join on. > > > > You can create another table for when a customer engages services for a > > specific project. This table would repeat the customer ID much like > > your Customers table. Let's call it Engagement > > EngagementID EngagementName CustomerCode ... > > 123 Connection Prob. 13458 > > > > Your Employee Table for time tracking - Consider renaming to something > > like EmployeeHours or Timesheet > > EmpID EngagementID ActivityDate ActivityFrom ActivityTo > > TimeSpent TaskID > > 789 123 9/28/2006 NULL NULL > > 2 90 > > > > NOTE: Depending on the design of your interface, you can inforce input > > of activity time from and to > > NOTE: Including the TaskID at the timesheet level allows much more > > flexibility. What if a customer want you to do 10 things. Are you > > going to set up 10 rows in the table that you named "customers" then > > have your employees pick from the list. These lists would grow > > considerably over time and they would require a lot of time on the part > > of team leaders to enter the projects commissioned by customers. This > > way you create one engatement and the emp. can charge multiple tasks to > > it. If you want to limit the tasks that are available for an > > engagment, use another table "EngagementTasks" with the engagmentID and > > taskID. > > > > Employee > > EmpID EmpName EmpAddress (you could even add some calculated > > fields like remaining vacation or sicktimetaken) > > 789 Bill Chicago 8 40 > > > > > > Ankith wrote: > > > Hi Everyone: > > > > > > I am trying to come up with a good db design for time tracking an employee's > > > time on one of the client projects that I am working on. The background is > > > as follows: > > > > > > 1). An Employee can work on administrative tasks and also some special > > > projects. > > > 2). An Employee can also work on customer issues. > > > 3). If an employee is on a vacation he will not work neither on any projects > > > or customer issues. > > > > > > The tables I have designed so far look like this: > > > > > > Table 1: > > > > > > Admin > > > --------- > > > AdminID > > > AdminDesc > > > > > > The Admin Desc can include: Vacation,General tasks,Sick,Training etc. > > > > > > Example data > > > > > > AdminID Desc > > > ------ ----- > > > 1 Vacation > > > 2 General > > > 3 Sick > > > 4 Training > > > 5 Time Tracking > > > > > > Table 2: > > > Projects > > > --------- > > > ProjectID > > > ProjectDesc > > > > > > The Project Desc can include: ProjectA, ProjectB, ProjectC etc. > > > > > > Example data > > > > > > ProjectID ProjectDesc > > > ------ ----------- > > > 1 ProjectA > > > 2 ProjectB > > > 3 ProjectC > > > 4 ProjectD > > > 5 ProjectE > > > > > > Table 3: > > > > > > Customers > > > --------- > > > CustomerID > > > Name > > > ProblemType > > > > > > The Customer Name can include: Customer1, Customer2, Customer3 etc. > > > The ProblemTypecan include: DR, Performance, Querytuning etc. > > > > > > Example data > > > > > > CustomerID Name ProblemType > > > ------ ----- > > > 1 Customer1 Disaster Recovery > > > 2 Customer1 Performance > > > 3 Customer2 Backup issue > > > 4 Customer3 Query Tuning > > > > > > Finally My EmployeeTable for Time tracking would be: > > > > > > Table 4: > > > > > > Employee > > > --------- > > > EmployeeID > > > EmployeeName > > > AdminID > > > ProjectID > > > CustomerID > > > Timespentinhrs > > > > > > Example Data: > > > > > > EmployeeID EmployeeName AdminID ProjectID CustomerID Timespentinhrs > > > 10 Rob 4 NULL NULL 2 > > > 10 Rob NULL 2 NULL 10 > > > 10 Rob NULL NULL 1 25 > > > 10 Rob NULL NULL 1 10 > > > 10 Rob NULL NULL 2 3 > > > > > > The total time spent by an employee > > > in the above case would be :50 > > >
Thanks. with few changes i think i have what i wanted.
[quoted text, click to view] "Bill" <wbpelen@yahoo.com> wrote in message
news:1159542355.539562.275310@i42g2000cwa.googlegroups.com... > The suggestions were not meant to be the entire solution. I would > certainly and columns to every one of the tables making sure that the > data is repeated as little as possible and that it all joins back so > that data can be broken down or joined to report on. > > As to your questions: Can I track time spent on a project for an > employee/for a customer? > If I understand the question - yes. > > The EngID on timesheet ties back to the engagement table which can > yield time spent on a project by one or all employees. The customer ID > is also on the Engagement table so this same join yields time spent by > customer. Also having the TaskID on the Timesheet table allows for > additional breakdowns of the data. Proper use of the sum function and > grouping of data should give you the results you are looking for. > > > Ankith wrote: >> Thanks for the suggestions. However I still have two questions. >> >> 1). How can I track the time spent on a project for an employee. You dont >> have >> the time for specific project in the timesheet table. >> 2). How can i tie the task spent for a customer?. >> >> I think the timesheet table might need one another column. Is that >> right?. >> >> Thx >> >> >> "wbpelen@yahoo.com" wrote: >> >> > Take these suggestions for what they are - the ramblings of a bored >> > programmer avoiding the unrewarding tasks on todays agenda. >> > >> > I may be completely off the mark but your design seems a little >> > circular and denormalized to me. >> > >> > Q1. Why separate admin from projects - Combine these into one table -- >> > their column definitions are identical - the ID can be assigned to the >> > timesheet. Consider adding a column to define the "Type". If you >> > really want to go crazy - Type can be a domain table all to itself and >> > the type column would be a number. I didn't do that here but you could >> > if your type list was determined to be large. >> > >> > ProjectID ProjectDesc Type >> > ------ ----------- ----------- >> > 1 ProjectA Task >> > 2 Vacation Admin >> > 3 ProjectC Task >> > >> > Customers - Consider NOT including a Problem type in a "Customer" >> > table. To do so would result in multiple rows per customer. A table >> > named customers should define a customer. >> > Customer >> > CustomerCode Name Address ... >> > 13458 Sea Watch Int'l >> > >> > Task >> > TaskID Description >> > 80 Open - Multiple Issues >> > 90 Connectivity >> > 91 Disaster Recovery >> > 92 Performance Tuning >> > >> > Space and speed are probably not an issue but integers take less space >> > than names and are much faster to join on. >> > >> > You can create another table for when a customer engages services for a >> > specific project. This table would repeat the customer ID much like >> > your Customers table. Let's call it Engagement >> > EngagementID EngagementName CustomerCode ... >> > 123 Connection Prob. 13458 >> > >> > Your Employee Table for time tracking - Consider renaming to something >> > like EmployeeHours or Timesheet >> > EmpID EngagementID ActivityDate ActivityFrom ActivityTo >> > TimeSpent TaskID >> > 789 123 9/28/2006 NULL NULL >> > 2 90 >> > >> > NOTE: Depending on the design of your interface, you can inforce input >> > of activity time from and to >> > NOTE: Including the TaskID at the timesheet level allows much more >> > flexibility. What if a customer want you to do 10 things. Are you >> > going to set up 10 rows in the table that you named "customers" then >> > have your employees pick from the list. These lists would grow >> > considerably over time and they would require a lot of time on the part >> > of team leaders to enter the projects commissioned by customers. This >> > way you create one engatement and the emp. can charge multiple tasks to >> > it. If you want to limit the tasks that are available for an >> > engagment, use another table "EngagementTasks" with the engagmentID and >> > taskID. >> > >> > Employee >> > EmpID EmpName EmpAddress (you could even add some calculated >> > fields like remaining vacation or sicktimetaken) >> > 789 Bill Chicago 8 40 >> > >> > >> > Ankith wrote: >> > > Hi Everyone: >> > > >> > > I am trying to come up with a good db design for time tracking an >> > > employee's >> > > time on one of the client projects that I am working on. The >> > > background is >> > > as follows: >> > > >> > > 1). An Employee can work on administrative tasks and also some >> > > special >> > > projects. >> > > 2). An Employee can also work on customer issues. >> > > 3). If an employee is on a vacation he will not work neither on any >> > > projects >> > > or customer issues. >> > > >> > > The tables I have designed so far look like this: >> > > >> > > Table 1: >> > > >> > > Admin >> > > --------- >> > > AdminID >> > > AdminDesc >> > > >> > > The Admin Desc can include: Vacation,General tasks,Sick,Training etc. >> > > >> > > Example data >> > > >> > > AdminID Desc >> > > ------ ----- >> > > 1 Vacation >> > > 2 General >> > > 3 Sick >> > > 4 Training >> > > 5 Time Tracking >> > > >> > > Table 2: >> > > Projects >> > > --------- >> > > ProjectID >> > > ProjectDesc >> > > >> > > The Project Desc can include: ProjectA, ProjectB, ProjectC etc. >> > > >> > > Example data >> > > >> > > ProjectID ProjectDesc >> > > ------ ----------- >> > > 1 ProjectA >> > > 2 ProjectB >> > > 3 ProjectC >> > > 4 ProjectD >> > > 5 ProjectE >> > > >> > > Table 3: >> > > >> > > Customers >> > > --------- >> > > CustomerID >> > > Name >> > > ProblemType >> > > >> > > The Customer Name can include: Customer1, Customer2, Customer3 etc. >> > > The ProblemTypecan include: DR, Performance, Querytuning etc. >> > > >> > > Example data >> > > >> > > CustomerID Name ProblemType >> > > ------ ----- >> > > 1 Customer1 Disaster Recovery >> > > 2 Customer1 Performance >> > > 3 Customer2 Backup issue >> > > 4 Customer3 Query Tuning >> > > >> > > Finally My EmployeeTable for Time tracking would be: >> > > >> > > Table 4: >> > > >> > > Employee >> > > --------- >> > > EmployeeID >> > > EmployeeName >> > > AdminID >> > > ProjectID >> > > CustomerID >> > > Timespentinhrs >> > > >> > > Example Data: >> > >
Don't see what you're looking for? Try a search.
|
January 2003
March 2003
April 2003
May 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
April 2008
| home · blog · groups | Questions? Comments? Contact the dn |