Results 1 to 3 of 3
  1. #1
    Join Date
    Oct 2012
    Posts
    1

    Calendar/Scheduling issue when designing a database

    Dear all,

    I am working on a project where each and every employee of the project's company would have his/her own calendar with the number of hours worked every day (employees should be allowed to make multiply records on every given day).

    There will be around 50 employees stored which will everyday make around 3 records each. (50emp x 3 records x 180 days = ~27k tuples )

    Manager then should be able to see every employee's schedule for the past 6 months(older than 6 months information can be deleted). Some further autocalculations of let's say total hours might be required.

    The following is the database diagram that I have come up with, but I am pretty sure that there should be a better way to implement the database for the needs.

    Any advice is much much appreciated.
    Attached Thumbnails Attached Thumbnails database.jpg  

  2. #2
    Join Date
    Feb 2004
    Location
    New Zealand
    Posts
    1,419
    Just a side not I would store the mins not the hours and just display mins in hour format

    Because 1:30 + 1:30 = hard work to work out

    Where 90 + 90 = 180min (180/60)
    hope this help

    See clear as mud


    StePhan McKillen
    the aim is store once, not store multiple times
    Remember... Optimize 'til you die!
    Progaming environment:
    Access based on my own environment: DAO3.6/A97/A2000/A2003/A2007/A2010
    VB based on my own environment: vb6 sp5
    ASP based on my own environment: 5.6
    VB-NET based on my own environment started 2007
    SQL-2005 based on my own environment started 2008
    MYLE
    YOUR PASSWORD IS JUST LIKE YOUR TOOTHBRUSH DON'T SHARE IT.

  3. #3
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Looks like a pretty simple implementation of a many-to-many relationship to me.
    More complexity would mean more functionality, and more functionality would mean more complexity, so where you go from here depends on your business requirements.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •