пытаясь выяснить лучшую схему базы данных - PullRequest
Новая
       21

пытаясь выяснить лучшую схему базы данных

1 голос
/ 10 октября 2009

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

Пока у меня есть 3 основных таблицы:

  1. Таблица контактов - обычная информация, такая как адрес, телефон и т. Д.
  2. Таблица событий - список событий с некоторой информацией, такой как дата, местоположение и т. Д.
  3. Таблица EventInfo - содержит следующие поля (не заполнены, но вы должны получить точку):

EventID
ContactID
NumberofAdultsInvited
NumberofChildrenInvited
Ответили (да, нет)
NumberofAdultsAttending
Количество детей, принимающих участие

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

Кажется странным, что мне нужны эти повторяющиеся поля для взрослых и детей, но я не могу придумать другого пути. Я не хочу помещать NumberAdults и NumberofChildren в таблицу контактов, потому что число детей не обязательно равно numberofChildreninvited (иногда приглашаются только взрослые)

У вас есть идеи, как я могу очистить эту схему, или это лучшее, что я могу получить?

ПРИМЕЧАНИЕ: В таблице контактов есть одна запись для семьи (так как она имеет один адрес), поэтому в семье нет полей, хранящихся на человека.

Ответы [ 3 ]

2 голосов
/ 10 октября 2009

Вот как я смоделирую базу данных на основе предоставленной информации:

EVENTS

  • EVENT_ID
  • ADDRESS_ID

INVITATIONS

  • CONTACT_ID
  • EVENT_ID
  • ОТВЕТИЛ

CONTACTS

  • CONTACT_ID

Не рекомендуется моделировать контакт, охватывающий всю семью. Это облегчает приглашение и отслеживание вещей, если контакт представляет человека, а не домохозяйство. В конце концов, домохозяйство может иметь от 0 до ~ 18 детей и может не включать в себя значимых других. Каждый человек, предполагающий подростковый возраст и возраст, будет иметь уникальную контактную информацию (например, мобильные телефоны, рабочие номера, адрес электронной почты и т. Д.). Это также облегчает определение численности персонала ...

Таблица приглашений позволяет суммировать приглашения и подтверждения: 

  SELECT e.event_name,
         SUM(invited.contact_id) 'total_invited',
         SUM(confirmed.contact_id) 'total_invitations_confirmed'
    FROM EVENT e
    JOIN INVITATIONS invited ON invited.event_id = e.event_id
    JOIN INVITATIONS confirmed ON confirmed.event_id = e.event_id
                            AND confirmed.responded = 'Y'
GROUP BY e.event_id, e.event_name

Просто нужно присоединиться к таблице КОНТАКТОВ, чтобы определить возраст, а затем иметь возможность подкатегоризировать приглашения между взрослыми и детьми.

FAMILIAL_RELATIONS

  • CONTACT_ID
  • RELATED_CONTACT_ID
  • RELATION_TYPE (родитель, ребенок, тетя / дядя, двоюродный брат, чернокожий и т. Д.)

Используйте эту таблицу для сведения членов домохозяйства ...

CONTACT_METHODS

  • CONTACT_ID
  • METHOD_TYPE (телефон, сотовый, бизнес-телефон, факс, электронная почта, IM и т. Д.)
  • METHOD_VALUE

CONTACT_ADDRESS_XREF

  • CONTACT_ID
  • ADDRESS_ID
  • ADDRESS_TYPE (дом, бизнес и т. Д.)

ADDRESSES

  • ADDRESS_ID
  • ADDRESS_1
  • ADDRESS_2
  • ADDRESS_3
  • ADDRESS_4
  • ГОРОД
  • PROV_STATE
  • POSTAL_CODE
  • СТРАНА

Вы заметите, что я установил отношения один-к-одному с EVENTS и ADDRESSES, поддерживая контакт один-ко-многим по адресам. Места будут относительно статичными по сравнению с людьми. Этот формат позволит вам легко определить, какие места проведения мероприятий популярны, и вы сможете использовать эту информацию, чтобы в будущем получить более выгодные тарифы.

Относительно адресов для одного и того же домохозяйства: вот почему АДРЕСА - это отдельная таблица - вам не нужно перепечатывать ее для каждого человека, просто укажите правильную адресную запись.

0 голосов
/ 10 октября 2009

Вам нужно отслеживать индивидуальные приглашения и ответы?

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

Если вы просто отслеживаете количество отсчетов, я могу нормализовать разделение таблиц для InvitationCount со столбцом дискриминатора для «Взрослый», «Ребенок» или что-то еще. Это позволяет избежать жесткого кодирования в вашей схеме только двух категорий приглашений. Perhpas в будущем у вас может быть больше категорий (например, клиенты, клиенты, участники, наблюдатели, исполнители, музыканты, доноры, почетные члены ...)

0 голосов
/ 10 октября 2009

[T] он связывается сейчас с целой семьей, так как одно приглашение отправлено одной семье

В этом случае, при отсутствии каких-либо других требований, я бы, вероятно, предложил маршрут, аналогичный тому, который вы уже предложили.

Избыточные поля не являются проблемой, поскольку они отслеживают уникальный факт о Invitation, а не о контакте.

Я бы, вероятно, сохранил отдельную таблицу для Response (с указанием количества посещаемых номеров, которое может отличаться от приглашенного номера) или для таблицы Attendee, но в действительности это не обязательно, учитывая ваши текущие требования.

...