search

faemir / teamproject

team project work
1 stars 0 forks source link

Populate Fixed SQL Tables once design agreed #15

Open JoshHughes-Dev opened 10 years ago

JoshHughes-Dev commented 10 years ago

Once database design agreed, populate fixed tables with all enduring data.

nikkwilliams commented 10 years ago

We aren't sure how to work facilities into the database without just having them as attributes.. that's very bad method but it's normalised and it works..

In the database design, I don't know how to have admin in the users table as the user (timetabler) is with a department whereas admin doesn't have a department.. maybe just give the admin account a null value for department..? On 26 Nov 2013 16:26, "Josh" notifications@github.com wrote:

Once database design agreed, populate fixed tables with all enduring data.

  • Departments
  • Modules
  • Room
  • Room Facilities?
  • Weeks
  • Users (create account for each department and one admin account for us and manager to use

— Reply to this email directly or view it on GitHubhttps://github.com/faemir/teamproject/issues/15 .

JoshHughes-Dev commented 10 years ago

I see what you mean about facilities. it was just interesting what ray dawson was saying in lecture, but if its normalised and works then im happy. Simple solutions can be the best for us.

With Users, i think we need to find a way to combine those two tables, because to me it seems wasteful and more complicated to be refering to two different tables when users login to our system. Perhaps have a department called admin? or we build into the table a column called access rights. This means we could say our solution has room for expansion to allow different kinds of users - (like lecturers, timetablers and admin)

nikkwilliams commented 10 years ago

The problem with facilities is maintenance.. adding or removing is extremely awkward with this method..

And yeah that makes sense. Something along those lines would be best On 26 Nov 2013 16:42, "Josh" notifications@github.com wrote:

I see what you mean about facilities. it was just interesting what ray dawson was saying in lecture, but if its normalised and works then im happy. Simple solutions can be the best for us.

With Users, i think we need to find a way to combine those two tables, because to me it seems wasteful and more complicated to be refering to two different tables when users login to our system. Perhaps have a department called admin? or we build into the table a column called access rights. This means we could say our solution has room for expansion to allow different kinds of users - (like lecturers, timetablers and admin)

— Reply to this email directly or view it on GitHubhttps://github.com/faemir/teamproject/issues/15#issuecomment-29308463 .

clownyXD commented 10 years ago

What I gathered from Ray Dawson was that the facilities table has one column, where you can add records of facilities. In SQL when a record is added to this table, it can then add a new attribute is it? to the rooms table? That's the impression I had, unless that's total bull. The other option is to have the one table we have already of 'Rooms' and to add a facility, you would amend it to this table? which is the original idea... but I don't know whether or not Ray Dawson likes this approach? Else why mention the approach on Monday, unless it's a red herring?