SharePoint Database/List Best Practices???

Anyone out there have a reference to what the best practices for programming SharePoint are?  Specifically, how much normalization one should use in their database/lists?  Here's my scenario:

I'd like to create a Time Off Request and Reporting application. It would have the following operation:

  • Employees would go to a form to request a period or day as PTO
  • Managers would be alerted to the request and either approve or deny it (which would then update the employee
  • When the scheduled day came, the manager would confirm that the employee did or didn't take the day off
  • Payroll would be able to run a report of the data to see who took what time off.  Managers could run the same report for their departments.  Employees could not.

With a normal database application, I'd have 4 related tables: Employees, Departments, Administrators (but actually, this could be a boolean field for the employee table), and the  PTOData table.  However, I'm not sure if you can write all of these within the context of SharePoint lists.  Anyone have any ideas?  Should I just create separate tables, and only use SharePoint as a wrapper?  Let me know what you think!

BTW – Dustin – I asked my manager if they'd send me to the dev training.  If I can go, this is something I'd like to cover.  For those of you who also would like to go, but are afraid of asking your boss for a few grand, I can send you my request document (the sucker was 2 1/2 pages long!) as a template.

Leave a Reply


SharePoint Database/List Best Practices???

Anyone out there have a reference to what the best practices for programming SharePoint are?  Specifically, how much normalization one should use in their database/lists?  Here's my scenario:

I'd like to create a Time Off Request and Reporting application. It would have the following operation:

  • Employees would go to a form to request a period or day as PTO
  • Managers would be alerted to the request and either approve or deny it (which would then update the employee
  • When the scheduled day came, the manager would confirm that the employee did or didn't take the day off
  • Payroll would be able to run a report of the data to see who took what time off.  Managers could run the same report for their departments.  Employees could not.

With a normal database application, I'd have 4 related tables: Employees, Departments, Administrators (but actually, this could be a boolean field for the employee table), and the  PTOData table.  However, I'm not sure if you can write all of these within the context of SharePoint lists.  Anyone have any ideas?  Should I just create separate tables, and only use SharePoint as a wrapper?  Let me know what you think!

BTW – Dustin – I asked my manager if they'd send me to the dev training.  If I can go, this is something I'd like to cover.  For those of you who also would like to go, but are afraid of asking your boss for a few grand, I can send you my request document (the sucker was 2 1/2 pages long!) as a template.

Leave a Reply