jason87 wrote:Hi califdon, dbemowsk and anyone else reading this,
Thanks for the tip on GET vars, didn't know that, I'm very new at this. I will put the whole code together later and post my result, be it triumph or plentiful bugs

My take on this is to create one table for dates and one for confirmations like dbemowsk suggested.
I would like to hear more about relational databases, although I'm not exactly sure what this term covers. In theory, I can see this system, albeit simple, working with many users, but I would like to know why it is not optimal. Will my current db structure get slow or are there just some rules-of-thumb regarding databases that I'm not complying to?
The only thing I, myself, have wondered, and I may very well be nitpicking, is that the confirmations table will contain confirmations in no particular order from all users, which doesn't seem very systematic?
Ah! You touched my hot button, Jason! Relational Databases!

I'll give you several references at the end of this post, but let me try to get your interest by explaining a few things very briefly:
Relational database theory was developed in the late 1960's by Dr. E. F. ("Ted") Codd, a mathematician at IBM, and Chris Date (I took a seminar from him once) and it remains the underlying principle on which nearly every database system and software is based, including MySQL, Access, Oracle, etc. Without that theory, we wouldn't have web search engines, airline reservation systems, financial systems, etc. etc.
We refer to Relational DataBase Management Systems, or RDBMS's. The idea behind an RDBMS is that one database may include data stored in multiple tables, which have "key" fields that enable them to be related, in simple or complex ways. But in order to work properly
and reliably, there are quite
strict rules that apply to what tables are needed and what fields must be in each table. When these rules are followed, the mathematical theory behind RDBMS absolutely guarantees certain desirable features, such as the
consistency of the data in your database. Quite often people will say something like, Well,
I didn't follow those rules, and
my database is working just fine! That may be true, but when some unplanned transaction occurs, or you want to make some changes in your data structure, you will have
no guarantee that it will continue to work. A properly designed relational database can enforce rules to assure data integrity under all conditions. I'm talking about operations like editing or deleting entries in a table which would then leave inconsistent or "orphan" data in another table.
To begin with, a database application should always begin with off-the-computer planning about the
data model. You can think of every database as a
model of some part of the real world, such as students in college classes, or financial transactions, or reservations on air flights, etc. etc. The very first consideration should be to define the
scope of your data model; will this model cover just
your classes, or
all the students, or
all the departments in the school, or what? You will need to identify what
entities will be represented in your data model. An entity is like a noun in grammar--a person, a place, an object, a transaction, an event, etc. For example, the entities for a hotel reservation system might be Rooms, Guests and Reservations.
This is a critical decision, because each entity requires one table in the database.
Then you must decide how much data you need to collect concerning each entity. Any entity has almost unlimited possible characteristics, but you only need to collect a small number of them. For the hotel system, for example, you need to know the Room Number, how many beds and what size, whether it is Smoking or Nonsmoking, maybe other characteristics, but you probably don't need to store the dimensions or color, etc.--although there might be some hotels that advertise special amenities such as a view of the ocean from some rooms, so it depends entirely on what is needed. But whether a room is occupied or has been reserved on a certain date are NOT characteristics of the entity Room, which is a point often confused by beginners. That information is part of an entirely different entity, the Reservation, and will be in that table, not the Rooms table. It is this sort of analysis that leads to a solid
schema for a database, that is, the structure of the tables. My major point is this: designing a schema is a careful and disciplined consideration of the data model and should never be merely someone's
opinion of what they think might work, despite what you will often read in forums like this one.
If you start with a properly designed schema, your PHP (or other language) routines will be simpler because most of the database related operations can then be handled with the standard features of SQL, without elaborate processing within the scripting or programming language. And your database will probably be simple to expand with additional data, features or to cope with new conditions, because of the logical consistency of your data.
So, if you like those concepts, here are some online tutorials I recommend:
http://www.tekstenuitleg.net/en/article ... tutorial/1
http://www.utexas.edu/its/archive/windo ... rview.html
http://jegsworks.com/Lessons/lesson1-2/ ... tabase.htm
http://www.phlonx.com/resources/nf3/
http://www.roseindia.net/jdbc/relationa ... epts.shtml
http://www.quackit.com/database/tutoria ... design.cfm
http://www.databasedesigning.com/Relati ... Model.html