|
Posted by Richard Levasseur on 03/30/06 08:12
Couple things:
- Since this is an internal system, delivery is gaurented and status
should would be better as read/unread, and perhaps 'deleted' if you
want to keep old messages around.
- To nit pick a bit: normalized (read: more or less 'proper') database
design doesn't allow for multiple values to be within a single field
(1st form violation? Can't recall exactly). This also eliminates the
need for the "owner" field, allows better indexing of "to", selection
with to, aggregate functions for things involving the "to" field.
- There doesn't need to be a record with status sent, that is implied
by someone receiving the message.
- If each row has a primary key id, then it would be better to perform
operations on the rows using the primary key, rather than a combination
of other keys that is unique (or just call that combination the primary
key, i personally feel its easier pass around a single id rather than a
combination of multiple fields)
So the table headers would become, in the instance A sends a message to
B, C, and D:
id | msgid | from | to | status
12 | 8 | A | B | unread
13 | 8 | A | C | read
14 | 8 | A | D | read
You're now storing 3 rows instead 4 and have eliminated a whole column.
Navigation:
[Reply to this message]
|