Question

I’m currently migrating a tonne of user data from CSV spreadsheets to an SQL database, designing the schema’s and all that jazz.

At this time, the Users table looks like this:

CREATE TABLE Users
(
    id      INTEGER NOT NULL AUTO_INCREMENT,

    name        VARCHAR(48) NOT NULL,
    alias       VARCHAR(24) NOT NULL UNIQUE,
    email       VARCHAR(128) NOT NULL,

    date_of_birth   DATE,
    location    VARCHAR(24) NOT NULL,

    date_joined DATE,

    ...

    PRIMARY KEY (id)
);

We (the group) are looking to soon test an email subscription service for certain events and write-ups; which will be managed by looking at who is subscribed in the database.

My initial thoughts were to just add a boolean value to the Users table, representing whether they are subscribed or not, but editing the schema like this seems like a bad practice.

My second thoughts were something like:

CREATE TABLE Subscribers
(
    uid     INTEGER NOT NULL,
    PRIMARY KEY (uid)
    FOREIGN KEY (uid) REFERENCES Users(id)
);

What are the pro-cons of the two approaches? Which would be most suitable for my situation, given the test may be experimental.

Answer 1

Advantages of the Subscribers table approach include:

• it is a higher — actually, the highest — normal form, being 6NF;
• it is more portable e.g. not all SQL products have a Boolean type;

There are further reasons in this article by Joe Celko.

The Subscribers table as posted has a few flaws, though. The uid columns should have a unique constraint. The auto-increment column is redundant. The foreign key should probably have the referential action ON DELETE CASCADE (and ON UPDATE CASCADE could prove useful in the future).