How to go about this?
Posted: Thu Mar 25, 2010 9:24 pm
Ok I’m developing a component for a CMS to help manage honours degree projects at a university (This is my honours project).
Because im using a CMS (Joomla) certain functionality like user registration and login is already taken care of as well as a basic user group system that can be used to define roles etc...
However i need to capture additional about the two main types of users which are: Lecturers and students. The crux of the problem is both students and lecturers will need to have very different information stored about them so I assume ill need two tables that both have a 1 to 1 relationship to the existing joomla users table.
Students need the ability to create a short-list of proposals they are interested in. So that's another table in a 1 to many relationship with the additional student_info table.
And there has to be a way to allow me to assign a student to a Lecturer but a lecturer can have multiple students assigned to him/her so there is another table required.
I'm just basically looking for some advice on how to model the database structure for this in an reasonably efficient way..once i understand how the logic of this should work programming it will be straightforward.
Just to try and explain this a bit further the basic functional requirements of the system are as follows:
• Enable staff to upload project proposals according to a template;
• Enable the Projects Co-ordinator to check proposals for duplicates;
• Enable students to browse, search and download project proposals;
• Enable students to prioritise interest in projects;
• Enable students to submit self proposed projects;
• Assist the Project Co-ordinator in allocating projects to students;
• Assist the Project Co-ordinator in tracking student progress throughout the year.
I already have my proposals table finished and the submit and searching of proposals working.
The reason i say that students and lecturers require very different information stored about them is because of the requirement that involves in tracking student progress throughout the year this will be quite a big table.
Because im using a CMS (Joomla) certain functionality like user registration and login is already taken care of as well as a basic user group system that can be used to define roles etc...
However i need to capture additional about the two main types of users which are: Lecturers and students. The crux of the problem is both students and lecturers will need to have very different information stored about them so I assume ill need two tables that both have a 1 to 1 relationship to the existing joomla users table.
Students need the ability to create a short-list of proposals they are interested in. So that's another table in a 1 to many relationship with the additional student_info table.
And there has to be a way to allow me to assign a student to a Lecturer but a lecturer can have multiple students assigned to him/her so there is another table required.
I'm just basically looking for some advice on how to model the database structure for this in an reasonably efficient way..once i understand how the logic of this should work programming it will be straightforward.
Just to try and explain this a bit further the basic functional requirements of the system are as follows:
• Enable staff to upload project proposals according to a template;
• Enable the Projects Co-ordinator to check proposals for duplicates;
• Enable students to browse, search and download project proposals;
• Enable students to prioritise interest in projects;
• Enable students to submit self proposed projects;
• Assist the Project Co-ordinator in allocating projects to students;
• Assist the Project Co-ordinator in tracking student progress throughout the year.
I already have my proposals table finished and the submit and searching of proposals working.
The reason i say that students and lecturers require very different information stored about them is because of the requirement that involves in tracking student progress throughout the year this will be quite a big table.