Дизайн базы данных групп людей - нужно посоветовать

Question

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

Мой вопрос касается организации людей в базе данных (я использую MySQL).

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

• Семейный
  • мама
  • папа
  • Jonathan
• Близкие друзья
  • David
  • Ronny
• Другие
  • Julia
  • Piter
  • Alex
• Таня (не принадлежит ни к одной группе)

Я думал о следующей организации в базе данных:

Таблица электронных писем (все пользователи, люди, электронные письма)

http://i38.tinypic.com/2586yol.jpg

Таблица групп (все группы пользователей)

http://i33.tinypic.com/2vkyoer.jpg

Таблица людей (все пользователи люди)

http://i33.tinypic.com/33uslg5.jpg

В таблице электронных писем не будет двух одинаковых электронных писем. name in Emails Table - это имя, которое пользователь дал человеку, когда он добавил свою электронную почту (я называю это именем по умолчанию). Каждый пользователь может иметь разные имена для одного и того же человека. Следовательно, для этого имя в People Table. name = NULL in People Table означает, что имя по умолчанию появится в дереве людей. group_id = NULL означает, что этот человек не принадлежит ни к одной группе.

Все это кажется разумным?

Кроме того, как вы можете видеть, между пользователями существует некоторый вид рассылки электронных писем. Это означает, что если Юлия изменила адрес электронной почты Дэвида, все другие пользователи также увидят это изменение (они получат электронное письмо об этом изменении). Как вы думаете, это может привести к проблемам?

Буду признателен за ваше мнение!

Answer 1

Oy. Данное письмо может быть связано с разными "людьми"? Я бы сказал, семантика этого довольно уродлива. Я бы переименовал таблицу людей в Контакты. Я также переименовал бы поле 'name' в таблице электронных писем в DefaultName, чтобы указать, что это строго запасной вариант.

За исключением семантики (что очень важно, если кто-то другой должен использовать эту базу данных), вы ссылаетесь на владельца как на внешний ключ, используя varchar (20). Нет никаких указаний на то, на что он ссылается, я предполагаю, что это какая-то таблица владельцев, с именем пользователя в качестве первичного ключа. Я бы порекомендовал суррогатный ключ int ... Что произойдет, если пользователь захочет изменить свое имя пользователя?

Наконец, сторонник меня изменил бы «групповые» контакты. Я бы сделал группу по умолчанию для каждого контакта, назвал бы это _Groupless и назначил бы «групповые» контакты, такие как Таня, для группы _Groupless. Приложение может разобраться в деталях. Мне не особо нравятся дополнительные внешние ключи.