On Feb 5, 2009, at 10:08 AM, Donohoe, Mark wrote: > Bob, > > Here are my thoughts on the tables changes needed to support email > notifications. This is the first time I have ever defined tables for a > db, so > if I'm doing something silly, please educate me. Thanks. > > Job table: > ---------- > replace job_submitter with user_pk,will need to change the type of the > column.
Yep. It never should have been a text name in the first place. > job_email_notify type changes to integer and is the foreign key to the > email notification table. > > email_notification table: > ------------------------- > relation of email table to job table is many to one. Many e-mail > tables to one job table. > > em_pk (primary key for the email notification table) > job_fk (job table key) > email_sent (timestamp or null) > user_fk (user foreign key, email sent on this users request) > email_addresses (comma seperated list of addresses used to send the > mail) Do we really want to have an audit trail of email sent (the email_notification table)? What's wrong with having a list of email addresses in the users table. After a job, the notification agent emails this list, which would be null if no notification is desired. Bob _______________________________________________ fossology mailing list [email protected] http://fossology.org/mailman/listinfo/fossology
