设计这个特定数据库/ SQL问题的最佳方法是什么？

Question

这是一个棘手的规范化/ SQL /数据库设计问题，令我们感到困惑。我希望我能正确地说出来。

您有一组活动。他们是需要完成的事情 - 一个荣耀的TODO清单。任何给定的活动都可以分配给员工。

每个活动都有一个活动的执行者。这些活动是联系人（人）或客户（业务）。每个活动都会有一个联系人或一个客户，他们将完成活动。例如，该活动可能是“向Spacely Sprockets（客户）发送感谢卡”或“向Tony Almeida（联系人）发送营销文献”。

从这个结构，我们就需要能够查询找到所有指定员工必须做的活动，在一个单一的关系，列出他们会是这样的在它最简单的形式：

----------------------------------------------------- 
| Activity | Description | Recipient of Activity | 
----------------------------------------------------- 

这里的想法是避免让联系人和客户有两列为空。

我希望我已经正确描述了这一点，因为这并不像第一眼那样明显。

所以问题是：什么是数据库的“正确”的设计，你将如何查询它来获取所需的信息？

Answer 1

这是我在它刺伤：

基本上你需要活动相关联，以1（接触或客户）和1名员工是做一个负责任的人的活动。请注意，您可以在像这样的模型中处理参照约束。

另外请注意我说的是连接所有人民和地方的businessEntity表。 （有时有用但不是必需的）。之所以把businessEntity的表你可以简单的参考的，应当负责和对活动的businessEntity的收件人，现在你可以有活动的任何和所有的人或地方预制和接收。

Answer 2

你必须像如下：

Activity | Description | Recipient Type

凡Recipient Type是Contact一个或Customer

你会再执行一个SQL SELECT语句如下：
Select * from table where Recipient_Type = 'Contact';

我意识到需要有更多的信息。

我们需要一个额外的表，它是代表接收者（联系人和客户）的：

此表应如下所示：

ID | Name| Recipient Type

Recipient Type将表中的一个关键参考最初在这篇文章中提到过。当然，需要完成工作来处理这些表中的级联，主要是更新和删除。因此，快速回顾一下：

Recipients.Recipient_Type是一个FK到Table.Recipient_Type

Answer 3

“正确”的设计，这个数据库是有一列的每个，你说你要设法避免。这允许在这两列和它们各自的表之间定义适当的外键关系。对引用两个不同表的键使用同一列会使查询变得丑陋，并且不能强制引用完整性。

活动表应该有外键的ContactID，客户ID

为了显示活动的员工：

SELECT ActivityName, ActivityDescription, CASE WHEN a.ContactID IS NOT NULL THEN cn.ContactName ELSE cu.CustomerName END AS Recipient 
FROM activity a 
LEFT JOIN contacts cn ON a.ContactID=cn.ContactID 
LEFT JOIN customers cu ON a.CustomerID=cu.CustomerID 

Answer 4

这听起来像一个基本的许多一对多的关系，我想它的模型本身。

Answer 5

[ActivityRecipientRecipientType] 
    ActivityId 
    RecipientId 
    RecipientTypeCode 
     ||| ||| |||_____________________________  
     |  |         | 
     |  --------------------    | 
     |      |    | 
    [Activity]    [Recipient]  [RecipientType] 
    ActivityId    RecipientId  RecipientTypeCode 
    ActivityDescription  RecipientName RecipeintTypeName 


    select 
     [Activity].ActivityDescription 
    , [Recipient].RecipientName 
    from 
     [Activity] 
    join [ActivityRecipientRecipientType] on [Activity].ActivityId = [ActivityRecipientRecipientType].ActivityId 
    join [Recipient] on [ActivityRecipientRecipientType].RecipientId = [Recipient].RecipientId 
    join [RecipientType] on [ActivityRecipientRecipientType].RecipientTypeCode = [RecipientType].RecipientTypeCode 
    where [RecipientType].RecipientTypeName = 'Contact' 

Answer 6

它为什么要定义客户和联系人作为独立的实体，当他们似乎是同一实体的版本是我不明白。在我看来，客户是联系人的附加信息。如果可能的话，我会建立联系的一个表，然后标记是客户的那些要么在该表中的字段，或通过添加自己的ID来已在它的扩展单客户信息表客户。

如果你不能做到这一点（因为这是被建立在现有的系统，其设计是固定的顶部），那么你有几种选择。没有一个选择是好的，因为它们无法真正解决原始缺陷，即单独存储客户和联系人。

1. 使用两列，一个NULL，以允许参照完整性工作。

2. 建设有其自身的PK和两列，一个NULL，中间表ActivityContacts指向客户或联系人。这可以让你建立一个“干净的”活动系统，但是会把丑陋推向那个中间表。 （它确实提供了一个可能的好处，那就是它允许您将活动的目标限制到添加到中间表的人员，如果这对您有利的话）。

3. 携带原设计缺陷到活动系统和（我在这里咬我的舌头）具有平行ContactActivity和CustomerActivity表。要查找员工分配的所有任务，请将这两个表一起放入一个VIEW中。这使您可以保持参照完整性，不需要NULL列，并为您提供从中获取报告的来源。

Answer 7

Actions 
Activity_ID | Description | Recipient ID 
------------------------------------- 
11 | Don't ask questions | 0 
12 | Be cool | 1 

Activities 
ID | Description 
---------------- 
11 | Shoot 
12 | Ask out 

People 
ID | Type | email | phone | GPS |.... 
------------------------------------- 
0 | Troll | troll@hotmail.com | 232323 | null | ... 
1 | hottie | hottie@hotmail.com | 2341241 | null | ... 


select at.description,a.description, p.* from Activities at, Actions a, People p 
where a."Recipient ID" = p.ID 
    and at.ID=a.activity_id 

result: 

Shoot | Don't ask questions | 0 | Troll | troll@hotmail.com | 232323 | null | ... 
Ask out | Be cool | 1 | hottie | hottie@hotmail.com | 2341241 |null | ... 

Answer 8

Answer 9

如果我读过的情况下正确的，收件人是客户和联系人的推广。
Gen-spec设计模式很好理解。

Data modeling question

Answer 10

模型的另一个实体：ActivityRecipient，将由ActivityRecipientContact和ActivityRecipientCustomer继承，这将保持适当的客户/联系人ID。

相应的表格将是：

Table: Activities(...., RecipientID) 

Table: ActivityRecipients(RecipientID, RecipientType) 

Table: ActivityRecipientContacts(RecipientID, ContactId, ...,ExtraContactInfo...) 

Table: ActivityRecipientCustomers(RecipentID, CustomerId, ...,ExtraCustomerInfo...) 

这种方式，你也可以有不同等栏目为每个收件人类型

Answer 11

我将修改客户和联系人的该定义。客户可以是个人或企业，对吗？在巴西，“pessoajurídica”和“pessoafísica”这两个词在直接（无意识的）翻译中成为“法人”（商业）和“自然人”（个人）。 Google提出了更好的翻译：“法律实体”和“个人”。因此，我们得到一个人表，并有一个'LegalEntity'和'个人'表（如果有足够的属性来证明它 - 这里有很多）。接收器成为Person表的FK。

哪里有联系？他们成为与人联系的桌子。由于联系人是与他人联系的人（例如：我的妻子是我的一些公司的注册联系人，我是客户）。人们可以有联系人。

注意：我使用了'Person'这个词，但您可以将其命名为'Customer'来命名该基表。