Database Design

[NFClimber]

Hi Everyone,

 I'm designing a PHP registration application, and just wanted to offer up my situation for some opinion on the database design.

 Basically, I have an application that will allow users to register students for classes. The classes are weekly, and the entire session is 5 weeks (So 5 sets of 1 week classes). Each class has a maximum amount of students it can take, and I want to add in the ability to close a class manually (as an administrator).

What I've done in the first revision of this program: I have a single table listing each class title, and multiple columns for each week, and the times available, and whether or not it was closed. This ended up being a table of like 35 columns, so I figure there has to be a better way.

If anyone has any thoughts about the general database architecture, I'm up for suggestions. I'm developing right now, so anything will certainly be helpful.

Cheers,

Grant

[laserlight]

You might want to read this article on database normalisation. That said, these days I tend to think in terms of entities, their attributes and relationships.

[NFClimber]

Great article - thanks!

I'm trying to think in those terms as well - I'm actually revising an application I wrote almost 5 years ago, one of my first projects. Everything is pretty much being rewritten from scratch, but with a time deadline I'm trying to get as much done as quickly as possible, but meeting all the standards. This article will be a great reference for the future as well, I'm sure.

Cheers,

Grant