Re: [SLUG] RFC: GradeBook Database, Part II

From: Paul M Foster (paulf@quillandmouse.com)
Date: Sun Nov 24 2002 - 19:55:59 EST


On Sun, Nov 24, 2002 at 01:40:44PM -0500, Russell Hires wrote:

> About a month ago I solicited comment about the my GradeBook project
> database. I made various recommended changes, and have posted the update to
> my server:
> http://www.village-smurf.com/GradeBook/schema_v2
>
> There's still a few things I'm unclear on, and I've also had trouble
> integrating all of the suggestions into one solution! :-)
>
> I appreciate all the help everyone has offered so far...
>

Drop the _tbl from all the table names. They're tables; you know it and
everyone else does too. This may also help you to thing of the rows in
these tables as _objects_.

Drop the Class_Schedule table. It duplicates the Classes table. In fact,
scour all these tables for duplicative fields. The only time you should
have a duplicate field in two tables is if it's being used as a primary
or foreign key; that is, it's used to tie the data in two tables
together. Otherwise eliminate it. See "normalization".

Make all your table names lowercase. If you're using PostgreSQL, this
will save you trouble later. It involved quoting and such, which is a
difficulty with PostgreSQL. I don't know about MySQL.

Create a teachers_classes table with teacher_id and class_id in it. As
you have it, there's no real way to cross reference these two things,
even though they obviously go together. Primary key would be the
class_id, since potentially you could have more than one teacher per
class.

It's not clear what the grades table is for. I assume it's for final
grades per semester? The work_item table seems like the same thing as
the assignments table. Grade_category table? Performance table? Don't
see what these are for.

You also need a table to tie students, courses, assignments and grades
together. In other words, you want a way to show each student's grade on
each assignment. You may not need the course_id field in this, if the
assignments_id is unique throughout the whole of the school.

You might also consider creating a set of *SQL queries to find out the
kind of information a school might want out of this database. This will
give you a better clue about what fields and tables you need. It will
also give you a feel for how queries need to be structured to get what
you want. I'm not talking about some GUI stuff. Just raw queries entered
at the *SQL command line. Be exhaustive about it. Think about what
teachers want to know, what administrators want to know, and what kids
might want to know.

HTH,

Paul



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:10:00 EDT