试图找出最好的数据库模式

Question

我想提出一个通用模式（如果可能）用于我正在管理的许多不同事件。这些活动可以是婚礼、生日聚会等。

到目前为止，我有 3 个主要表格：

1. 联系方式表 - 通常的信息，如地址、电话等。
2. 活动表 - 一个包含日期、位置等信息的事件列表。
3. EventInfo Table - 包含以下字段（不完整，但您应该明白要点）：

EventID
联系方式
受邀成人人数
受邀儿童人数
已回复（是、否）
参加的成人人数
NumberofChildrenAttending

这是我正在尝试改进的表。我正在尝试找出捕获事件数据的最佳方法，以便跟踪成人和儿童的数据。

似乎很奇怪，我需要成人和儿童的这些重复字段，但我想不出任何其他方法。我不想将 NumberAdults 和 NumberofChildren 放入联系人表中，因为儿童数量不一定等于 numberofChildreninvited （有时成人只是邀请）

您对如何清理此架构有任何想法吗？或者以上是我能得到的最好的想法吗？

注意：在联系人表中，家庭有一个条目（因为它有一个地址），因此不会为家庭中的每个人存储字段。

Answer 1

以下是我根据提供的信息对数据库进行建模的方法：

EVENTS

• EVENT_ID
• ADDRESS_ID

INVITATIONS

• CONTACT_ID
• EVENT_ID
• RESPONDED

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
• CITY
• PROV_STATE
• POSTAL_CODE
• COUNTRY

您会注意到我与 EVENTS 和 ADDRESSES 建立了一对一的关系，同时支持一对多的联系地址。与人相比，位置将相对静态。通过这种格式，您可以轻松查看哪些活动地点很受欢迎，以便您将来可以使用这些信息获得更好的价格。

关于同一家庭的地址：这就是为什么 ADDRESSES 是一个单独的表 - 您不需要为每个人重新输入它，只需关联到正确的地址记录即可。

Answer 2

您需要跟踪单独的邀请和回复吗？

如果是这样，您可以有一个单独的邀请及其状态表。然后您可以从对该表的查询中获取计数。

如果您只是简单地跟踪计数，我可能会将 InvitationCount 的单独表标准化为成人、儿童或其他任何内容的鉴别器列。这避免了仅将两类邀请硬编码到您的架构中。也许将来你可能会有更多类别（例如顾客、客户、参与者、观察员、表演者、音乐家、捐赠者、荣誉会员......）

Answer 3

[T]现在的联系人是整个家庭，因为一张邀请函发送给一个家庭

在这种情况下，如果没有任何其他要求，我可能会建议采用与您已经提议的类似的路线。

冗余字段不是问题，因为它们跟踪的是有关邀请的独特事实，而不是联系人。

我可能会为 Response（包含出席人数，可能与受邀人数不同）或 Attendee 表保留一个单独的表，但考虑到您的情况，这并不是真正必要的当前的要求。