Question

I’m attempting to design a small database for a customer. My customer has an organization that works with public and private schools; for every school that’s involved, there’s an implementation (a chapter) at each school.

To design this, I’ve put together two tables; one for schools and one for chapters. I’m not sure, however, if I should merge the two together. The tables are as follows:

mysql> describe chapters;
+--------------------+------------------+------+-----+---------+----------------+
| Field              | Type             | Null | Key | Default | Extra          |
+--------------------+------------------+------+-----+---------+----------------+
| id                 | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| school_id          | int(10) unsigned | NO   | MUL |         |                |
| is_active          | tinyint(1)       | NO   |     | 1       |                |
| registration_date  | date             | YES  |     | NULL    |                |
| state_registration | varchar(10)      | YES  |     | NULL    |                |
| renewal_date       | date             | YES  |     | NULL    |                |
| population         | int(10) unsigned | YES  |     | NULL    |                |
+--------------------+------------------+------+-----+---------+----------------+
7 rows in set (0.01 sec)

mysql> describe schools;
+----------------------+------------------------------------+------+-----+---------+----------------+
| Field                | Type                               | Null | Key | Default | Extra          |
+----------------------+------------------------------------+------+-----+---------+----------------+
| id                   | int(10) unsigned                   | NO   | PRI | NULL    | auto_increment |
| full_name            | varchar(255)                       | NO   | MUL |         |                |
| classification       | enum('high','middle','elementary') | NO   |     |         |                |
| address              | varchar(255)                       | NO   |     |         |                |
| city                 | varchar(40)                        | NO   |     |         |                |
| state                | char(2)                            | NO   |     |         |                |
| zip                  | int(5) unsigned                    | NO   |     |         |                |
| principal_first_name | varchar(20)                        | YES  |     | NULL    |                |
| principal_last_name  | varchar(20)                        | YES  |     | NULL    |                |
| principal_email      | varchar(20)                        | YES  |     | NULL    |                |
| website              | varchar(20)                        | YES  |     | NULL    |                |
| population           | int(10) unsigned                   | YES  |     | NULL    |                |
+----------------------+------------------------------------+------+-----+---------+----------------+
12 rows in set (0.01 sec)

(Note that these tables are incomplete – I haven’t implemented foreign keys yet. Also, please ignore the varchar sizes for some of the fields, they’ll be changing.)

So far, the pros of keeping them separate are:

1. Separate queries of schools and
   chapters are easier. I don’t know if
   it’s necessary at the moment, but
   it’s nice to be able to do.
2. I can make a chapter inactive
   without directly affecting the
   school information.
3. General separation of data – the fields in
   “chapters” are directly related to
   the chapter itself, not the school
   in which it exists. (I like the
   organization – it makes more sense
   to me. Also follows the “nothing but the key” mantra.)
4. If possible, we can collect school
   data without having a chapter
   associated with it, which may make
   sense if we eventually want people
   to select a school and autopopulate
   the data.

And the cons:

1. Separate IDs for schools and
   chapters. As far as I know, there
   will only ever be a one-to-one
   relationship between the two, so
   doing this might introduce more
   complexity that could lead to errors
   down the line (like importing data
   from a spreadsheet, which is unfornately
   something I’ll be doing a lot of).
2. If there’s a one-to-one ratio, and
   the IDs are auto_increment fields,
   I’m guessing that the chapter_id and
   school_id will end up being the same – so why not just put them in a single table?
3. From what I understand, the chapters
   aren’t really identifiable on their
   own – they’re bound to a school, and
   as such should be a subset of a
   school. Should they really be
   separate objects in a table?

Right now, I’m leaning towards keeping them as two separate tables; it seems as though the pros outweigh the cons, but I want to make sure that I’m not creating a situation that could cause problems down the line. I’ve been in touch with my customer and I’m trying to get more details about the data they store and what they want to do with it, which I think will really help. However, I’d like some opinions from the well-informed folks on here; is there anything I haven’t thought of? The bottom line here is just that I want to do things right the first time around.

Answer 1

I think they should be kept separate. But, you can make the chapter a subtype of a school (and the school the supertype) and use the same ID. Elsewhere in the database where you use SchoolID you mean the school and where you use ChapterID you mean the chapter.

CREATE TABLE School (
   SchoolID int unsigned NOT NULL AUTO_INCREMENT,
   CONSTRAINT PK_School PRIMARY KEY (SchoolID)
)

CREATE TABLE Chapter (
   ChapterID int unsigned NOT NULL,
      CONSTRAINT PK_Chapter PRIMARY KEY (ChapterID)
      CONSTRAINT FK_Chapter_School FOREIGN KEY (ChapterID) REFERENCES School (SchoolID)
)

Now you can’t have a chapter unless there’s a school first. If such a time occurred that you had to allow multiple chapters per school, you would recreate the Chapter table with ChapterID as identity/auto-increment, add a SchoolID column populated with the same value and put the FK on this one to School, and continue as before, only inserting the ID to SchoolID instead of ChapterID. If MySQL supports inserting explicit values to an autoincrement column, then making it SchoolID autoincrement ahead of time could save you trouble later (unless switching a regular column to autoincrement is supported in which case no issues there).

Additional benefits of keeping them separate:

• You can make foreign key relationships directly with SchoolID or ChapterID so that the data you’re storing is always correct (for example, if no chapter exists yet you can’t store related data for such a thing until it is created).
• Querying each table separately will perform better as the rows don’t contain extraneous information.
• A school can be created with certain required columns, but the chapter left uncreated (temporarily). Then, when it is created, you can have some NOT NULL columns in it as well.