Какова лучшая структура реляционной базы данных для этой простой контактной формы? - PullRequest
0 голосов
/ 04 декабря 2018

enter image description here

1 - Сообщение принадлежит имени, Имя принадлежит электронной почте, а электронная почта принадлежит номеру телефона

2 - Сообщение принадлежит электронной почте, электронная почта принадлежитимя и имя принадлежат номеру телефона

3 - многие сообщения могут указывать на один адрес электронной почты и имя и номер телефона.Сообщение принадлежит электронной почте, сообщение принадлежит имени, сообщение принадлежит номеру телефона.

Или есть какая-то лучшая структура, которая бы удовлетворяла нормализации.Целью этого является сохранение данных, чтобы телеколлер мог впоследствии связаться с человеком, с которым связался, по электронной почте и номеру телефона

1 Ответ

0 голосов
/ 04 декабря 2018

Вы не правильно сформулировали свои требования.Поэтому мы не можем предоставить точное решение.

Сущность

Вместо того, чтобы думать о столбцах и полях, подумайте о сущностях .Каковы реальные вещи, которые вы пытаетесь отследить в своей базе данных и приложении.

Если вы используете систему планирования встреч для ветеринарной практики, у вас есть несколько организаций: Клиент, Животное, Доктор, MedicalAssistant, Назначение /Визит.

Если ваши сотрудники отслеживания общаются, у вас есть Сотрудник и Сообщение.

Атрибут

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

Отношения и мощность

Если вы хотите посмотреть адрес электронной почты или телефон сотрудника, но отслеживать сообщения независимо от способа связи, у нас есть две таблицы.Связь заключается в том, что у каждого сотрудника может быть ноль, одно или несколько сообщений, и в каждом сообщении должен быть ровно один сотрудник.Это количественное определение связанных строк между таблицами формально известно как кардинальность .

В моем ASCII-искусстве эквивалент ворон-футов Диаграмма ERD :

[сотрудник] -1 ----- 0-1 - <[сообщение] </p>

Что касается столбцов в этих таблицах:

  • Текущее имя, текущий адрес электронной почты и текущий номер телефона офиса - все атрибуты (столбцы) в таблице employee.
  • В таблице message есть столбец content.

Ключи

Таблица employee также должна иметь столбец первичный ключ .Первичным ключом обычно является идентификатор столбец (автоинкрементная последовательность целых чисел) или UUID .

Таблица message в виде стены содержит столбец первичного ключа.Кроме того, в таблице message должен быть столбец внешний ключ .Столбец внешнего ключа содержит значение первичного ключа сотрудника, которому было отправлено сообщение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...