I am working on a Project Management application, and I have two data design issues I am debating.
The key element of this app, as you might expect, is Project. The project will proceed through many phases, from Planning, to Pre-Design, Design, Bid, Construction and Post Construction. All along the way there are a number of discrete tasks that must be performed and tracked.
I bounce back and forth in my mind between a single Project table that encapsulates all of these tasks, but am hesitant because I'm not a big fan of large monolithic tables. Alternatively, I could logically create separate tables for the various phases. However, this would create a series of one-to-one relationships between Project and the Phase tables, and require extra joins. The performance hit would probably not be too bad, but I would need to add extra code in either the app code or stored procedures to create an empty record in each of the phase tables when a new project is added. (Obviously, projects in planning or design will not have active records in the Construction and Post Construction tables). What are your thoughts about these choices?
Secondly, I have to manage data for a lot of individuals, which basically break down into two groups. First are internal employees who will have tasks routed to them, be invited to meetings, etc. Second are external vendors, basically contractors and consultants, who will be performing work and also be invited to meetings and such. I need to track the participants in meetings and inspections, so will have a Meeting Participant table to capture the many-to-many relationship. My issue is structuring the handling of the people. One option is to have a Person table, which basically includes everybody, with a flag field for internal or external people, and categories for their roles. Second is a table for internal folks and a table for external, or separate tables for Consultants, Contractors, and internal Employees. However, this makes capturing the meeting participants more cumbersome.
What is the collective wisdom on these? Thanks!
Jeff LittleThe place to start is the Time Tracker starter kit table design and make modification as needed. The second place is to test drive Enterprise Project Server it comes with Database templates for OLTP and OLAP to build cubes for the project. Check the link below for a demo I attended a while back with OLAP cubes, you can also search the TechNet site for more Project demos. Hope this helps.
http://www.microsoft.com/technet/community/events/project/tnt1-64.mspx
Kind regards,
Gift Peddie|||Here's my suggestion:
Project (ProjectID, ...)
Task (ProjectID, PhaseID, TaskID, TaskTypeID, TaskName, ...)
Phase (PhaseID, Name, ...)
TaskType (TaskTypeID, Name, ...)
Person (PersonID, PersonTypeID, PersonName, Username, ...)
PersonType (PersonTypeID, Name, Internal Bit, ...)|||Hi Jeff,
First off I would go with the idea of multple tables for the project instead of one. I have seen way to many applications where the number of fields and record length is outrageous given that most of the time a third to a half of the fields aren't populated. As for your concerns about adding an empty record, why? Simply do an outer join, where no matching record exists the field values from the applicable table will be null.
Lastly, people are people unless there is some compelling reason such as significant data requirements for internal as opposed to external they belong in the same table.
Cheers