2014-01-18 3 views
0

Я хочу создать БД для PHP Mailer App. Программа позволит пользователю войти в систему. После входа пользователя в систему они смогут написать «Отправить» по электронной почте, теме, из и выбрать Выпадающее меню формы HTML-шаблона. У меня есть понимание того, как это сделать, но поскольку я не так хорош в разработке базы данных, я решил обратиться за помощью сюда.Mysql Relation DB для почтовой программы

Так что я identyfied 3 таблицы:

Users[id, firstname, lastname, email, password] 
Message[id, send_to, subject, template_used, from, date, ip_address] 
Template[id, temp_name, temp_html]. 

Я борюсь с понятиями реляционных баз данных, но это, как я вижу это:

пользователя 1 .. * ------- ---- 1 .. * Сообщение, сообщение 1..1 ----------- 1..1 Шаблон, Шаблон 1..1 -------- 1 .. * Пользователи

Не уверен в отношении этих отношений, и если связь между пользователем и сообщением правильная, это проблема, когда две таблицы составляют 1 .. * .....?

+0

Уточните, пожалуйста, свой вопрос? - это должно быть «Пользователь 1 .. * ----- 1..1 Сообщение, сообщение 1..1 ------- * .. 1 Шаблон, Шаблон * .. * Пользователи – Vishal

ответ

0

Хорошая база данных в реляционной модели требует, чтобы таблицы, по крайней мере, соответствовали третьему правилу нормировки (3N). Пожалуйста, прочитайте что-нибудь о 1N 2N 3N. В настоящее время существующие отношения должны быть уменьшены до (один слишком много). Их не может быть много, если вы ожидаете прекрасного RD. Давайте проанализируем отношение таблиц пользователя к сообщениям: Ситуация 1: У одного пользователя может быть много сообщений, то есть (пользователь ---- сообщений) ---- (один для многих) Одно сообщение может быть для многих пользователей, Т.е. (сообщение ----- пользователи) ----- один для многих Это означает, что сообщения для пользователей имеют много-много отношений. По правилам нормализации это неверно (ради ссылочной целостности). Этого можно избежать, представив другую таблицу, которая будет действовать как посредник, назовите ее (messageuser). Эта таблица будет содержать первичный ключ внешнего ключа и внешнего ключа пользователя в качестве первичного ключа, таким образом, составного ключа. Что мы замечаем:

(Рисунок: простая иллюстрация, а не стандартная). Извините, я не смог загрузить изображение, чтобы показать вам, что в соответствии с правилами и политикой сайта.

Теперь у нас есть три таблицы с двумя отношениями с каждым в виде (один на многие). i.e пользователь usermessage (один пользователь имеет одно сообщение с его идентификатором) и сообщение пользователю (одно сообщение отправляется одному пользователю с определенным идентификатором). Разве это не здорово.

Смежные вопросы