试图找出最好的数据库架构

时间:2009-10-10 13:06:38

标签: sql database-design schema data-modeling

我想提出一个通用模式(如果可能的话),用于我正在管理的许多不同事件。这些活动可以是婚礼,生日派对等。

到目前为止,我有3个主要表格:

  1. 联系表 - 地址,电话等常用信息
  2. 活动表 - 包含日期,地点等信息的活动列表。
  3. EventInfo表 - 包含以下字段(不完整,但您应该明白这一点):
  4. 事件ID
    使用ContactID
    NumberofAdultsInvited
    NumberofChildrenInvited
    回应(是,否)
    NumberofAdultsAttending
    儿童会议号码

    这是我正在努力改进的表格。我试图找出捕获事件数据的最佳方法,我们希望跟踪成人和儿童的数据。

    似乎很奇怪,我需要成人和儿童的这些重复的领域,但我想不出任何其他方式。我不想将NumberAdultsNumberofChildren放在联系人表格中,因为孩子的数量不一定等于numberofChildreninvited(有时会邀请成年人)

    您对我如何清理此架构有什么想法,还是我能得到的最好的?

    注意:在联系表中,该系列有一个条目(因为它有一个地址),因此系列中没有每个人存储的字段。

3 个答案:

答案 0 :(得分:2)

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

EVENTS

  • EVENT_ID
  • ADDRESS_ID

INVITATIONS

  • CONTACT_ID
  • EVENT_ID
  • 响应

CONTACTS

  • CONTACT_ID

将联系人建模为包含整个家庭并不是一个好主意。这样可以更容易地邀请和如果联系人代表一个人而不是一个家庭,则跟踪事物。毕竟,一个家庭可以有0到18个孩子的任何地方,并且可能不包括重要的其他孩子。每个人,假设青少年和将有独特的联系信息(IE:手机,工作号码,电子邮件等)。这也使得更容易确定人数......

邀请表可让您汇总邀请函&确认:

  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

只需要加入CONTACTS表来确定年龄,然后就可以将成人和成员之间的邀请分类。孩子。

FAMILIAL_RELATIONS

  • CONTACT_ID
  • RELATED_CONTACT_ID
  • RELATION_TYPE(父母,孩子,阿姨/叔叔,堂兄,黑人等)

使用此表汇总以获得家庭成员......


CONTACT_METHODS

  • CONTACT_ID
  • METHOD_TYPE(手机,手机,商务电话,传真,电子邮件,即时消息等)
  • 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

您会注意到我与EVENTSADDRESSES建立了一对一的关系,同时支持与地址进行一对多的联系。与人相比,地点相对静止。这种格式可以让您轻松检查哪些活动地点很受欢迎,因此您可以使用这些信息在未来获得更好的价格。

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

答案 1 :(得分:0)

  

[T]他现在联系的是整个家庭,因为一个邀请被发送给一个家庭

在这种情况下,如果没有任何其他要求,我可能会提出与您已经提出的相似的路线。

冗余字段不是问题,因为它们正在跟踪关于Invitation的唯一事实,而不是联系。

我可能会为Response(参加号码,可能与邀请号码不同)或Attendee表保留一个单独的表格,但根据您当前的要求,这并不是必需的。

答案 2 :(得分:0)

您是否需要跟踪个人邀请和回复?

如果是这样,您可以为邀请及其状态设置单独的表格。然后,您可以从针对该表的查询中获取计数。

如果您只是记录计数,我可以规范化,以将InvitationCount的表与Adult,Child或其他任何内容的分隔符列分开。这样可以避免将两种类型的邀请硬编码到您的架构中。未来的Perhpas你可能会有更多的类别(例如,客户,客户,参与者,观察者,表演者,音乐家,捐赠者,名誉成员......)