Database efficiency/structure issue

问题

I'm writing a simplified version of an email system on a site I'm creating.

The basic premise is users can message each other on the site, best example would be ebay, you can message other users on the site itself and it basically acts as an email system.

What I have is the messages themselves, who they're from, to and the text.

I would also like to have basic "read/not read" and "deleted", possibly even "sent" categories.

something like this:

table structure:

id, to, from, subject, body, dateTime

What I'd like to know is if it makes more sense to just add a "read" and "deleted" column to that table, and search for those particular conditions, when I need them on the site, or if it is more efficient/best practice to have another "categories" table and then have a join table putting a message id with category id, and then using that join table to serve up the info when it's requested?

If my question doesn't make sense forgive me, I'm still pretty new at this stuff.

回答1:

i would add two columns:

read tinyint(1),
deleted tinyint(1)

and use them as booleans.

回答2:

I've just implemented something similar. I put the column right in the "message" table. I chose the following:

ReadDate DATETIME DEFAULT NULL,

If the message hasn't been read, ReadDate is NULL. When the user has read it, I fill in the date it was read. This allows the sender to know when it was read by the receiver.

回答3:

I would create three tables for this system. One for your threads (group of messages), one for your actual messages and another one for your categories.

Something like this,

MessagesThreads
--------------------
id (int, serial)
from (int, foreign: Users.id)
to (int, foreign: Users.id)
subject (varchar)
category (foreign key: Categories.id)

MessagesContent
--------------------
id (int, serial)
threadId (int, foreign: MessagesThreads.id)
content (text)
date (datetime)
status (tinyint) (0 for unread, 1 for read, 2 for deleted, for instance)

Categories
--------------------
id (int, serial) 
name (varchar)

This would be a properly normalised database.

With this, a thread can contain one-to-many messages (because the foreign key is in MessagesContent), a message is attached to only one tread and a thread can have one category.

I think this is the most efficient way for storing your messages, according to your specifications.

回答4:

Given a user account table like this:

CREATE TABLE tbl_accounts(
    id INT NOT NULL AUTO_INCREMENT,
    PRIMARY KEY(id),
    email_addr VARCHAR(50) NOT NULL,
    passkey BLOB /* AES KEY */
) ENGINE = InnoDB;

You will need a mail box table to find an email depending on the user account & the folder they are checking (inbox|outbox). We separate this table keep the database "normalised".

CREATE TABLE tbl_email_box(
    account_id INT, /* owner|sender of mail */
    FOREIGN KEY (account_id) REFERENCES tbl_accounts(id) ON DELETE SET NULL,
    email_id INT,
    FOREIGN KEY (email_id) REFERENCES tbl_emails(id) ON DELETE SET NULL,

    folder TINYINT(1), /* 0=inbox->account=owner; 1=outbox->account=sender; */

    status TINYINT(1) DEFAULT 0, /* 0=unread, 1=read */

    date TIMESTAMP     /* because the query executes when they check/send mail, */
                       /* then record is created (date=sent|received date) */
) ENGINE = InnoDB;

This table will store the actual email data

CREATE TABLE tbl_emails(
    id INT NOT NULL AUTO_INCREMENT,
    PRIMARY KEY(id),
    subject VARCHAR(100),
    message BLOB,
    created TIMESTAMP
) ENGINE = InnoDB;

Hope this helps.

来源：https://stackoverflow.com/questions/10175076/database-efficiency-structure-issue

标签

php

mysql

database

normalization