
There are 5 tables that make up the DB for the Daily Messages system:
adminuser, message, category, email, and email_content.
 

The adminuser table is simply a username/pw pairing that determines
who gets admin access to the tool. The admin users have NO overlap
with LDAP users.

adminuser
  adminuser_id   int         not null   autoincrement  primary key
  username       varchar(16) not null                  index
  password       varchar(32) not null


The message table contains all the actual message data and metadata.
  message_id         int         not null   autoincrement  primary key
  datetime_created   datetime    not null
  submitter_userid   varchar(12) not null
  submitter_name     varchar(48) not null
  submitter_email    varchar(96) not null
  submitter_phone    varchar(16) not null
  submitter_org      varchar(48) not null
  audience_students  tinyint(1) default false,
  audience_faculty   tinyint(1) default false,
  audience_staff     tinyint(1) default false,
  audience_other     tinyint(1) default false,
  audience_extra1    tinyint(1) default false,
  audience_extra2    tinyint(1) default false,
  headline           varchar(65) not null
  short_body         text
  long_body          text
  active_date        datetime
  short_summary      varchar(65)
  summary_datetine   datetime
  submitter_comment  varchar(255)
  refused_flag       tinyint(1) default false
  to_publish_flag    tinyint(1) default false
  published_flag     tinyint(1) default false
  publish_datetime   datetime
  to_foreshadow_flag tinyint(1) default false
  foreshadowed_flag  tinyint(1) default false
  category_id        int
  ordering           int
  admin_comment      text
  
NOTE: since we have the submitter's user_id we don't actually need to
collect their email, phone, name, etc from a web form since that info
is available via LDAP. However, it's handy to store it in the DB to
get a snapshot of the info at the time the message was created.

NOTE: there is no in-DB way to determine whether or not a given
address/user is a member of a given audience - that business logic
needs to be implemented outside the DB. Possibly it's hardcoded,
possibly it's based on LDAP attributes, possibly little gnomes deal
with it, but regardless it's not handled here.

NOTE: another viable approach to audiences would be to have separate
audience definition and linking tables, but since our audience set is
supposed to be stable it seems worth saving the complexity. Just in
case the audience set does need to expand I've added two buffer spaces
for them (space is cheap). If going with the multi table approach it
would look like this

   The audience table contains lists of which audience(s) for which a
   messages is intended.
     audience_id
     audience_name 
   
   The message_audience table links messages with audiences.
     message_audience_id
     message_id
     audience_id



The category table has the categories into which messages may be
placed.
  category_id
  category_name
  ordering

NOTE: the ordering determines both the order in which the category
appears in the drop down for admin assignment and the order in which
the categories appear in the email.


The email table contains the text of each email in addition to
providing an ID and a place to record a date.
  email_id           int
  email_built        datetime
  text_for_students  text
  text_for_faculty   text
  text_for_staff     text
  text_for_other     text
  text_for_all_combined text

The email content table groups messages together into emails. It is
constructed each midnight before publication.
  email_id           int
  message_id         int
  foreshadow_flag    tinyint
