Question

我有很多桌子：顾客，潜在客户，朋友...... 他们都有一些笔记。

问题1：我是否应该与所有父表共享一个Notes表 OR
我应该有NotesCustomer，NotesProspects，NotesFriends表吗？

问题2：
如果最好的解决方案是第一个，那么这个通用Notes表应该有一个FK到父表但是也是父表的类型？

我正在使用EntityFramework，但这个问题也很普遍，我猜...

由于乔恩

Answer 1

第一个选项是潜在客户，客户和朋友的独特Notes表，可能是一个更清洁的解决方案。

如果使用常规注释表，则需要有三个可空的FK列来确定FK所属的相关表，每行中只填充其中一个。

一般来说，良好关系模型的目标不是（或不一定）将类似数据存储在一起，而是仅存储一次特定数据。因此，在设计这个问题时要问自己一个很好的问题是“通过将所有笔记存储在同一个表格中我获得了什么？”

Answer 2

第一个选项是最好的一个Notes表与所有其他选项共享。

您可以使用两个字段notes_obj_id和notes_obj_type来实现表格一般注释

Answer 3

我直觉上更喜欢一种表格方法，但它也有其缺点。 Pro one-table：如果您需要更改其结构，则创建具有相同结构的多个表可能会很痛苦。此外，每当您查询注释而不是逻辑上更干净的“type”参数时，您都必须为表名添加变量。然而，菲尔的论点也很有趣。您可能还会发现，单表布局最终可能会使用仅使用SQL无法轻松查询的数据库。如果您将拥有大量数据，那么使用不同的表格也会给您带来速度差异。

嗯。一个非常干净但也有点复杂的解决方案是创建一个表NotableObject。然后给每个客户，潜在客户，无论字段“NotableObjectID”如何，并将注释链接到NotableObjects，而不是链接到客户或潜在客户。当然，如果你想要“给我所有关于顾客的笔记”之类的东西，这会使事情变得复杂，因为你只是明确地存储来自顾客的信息而不是反转，但是因为在大多数情况下，你会有更像“给我这个顾客的所有笔记“，你可能没事。

Answer 4

您应该只有一个Notes表。关系从Notes流向其他实体（它是0：M），因此不需要在Notes表级别拥有FK列。 Notes表上的Prospect，Customer，Friend的FK列只会导致设计，每当新实体需要Notes时，您需要继续将FK列添加到Notes表中（这实际上不会加快速度）。

例如，如果您想获得所有Prospect注释的列表，只需查询Prospect表并使用连接，如果您必须获得注释详细信息：

select n.NoteId, n.NotesDetail from Prospect p inner join Notes n 
    on p.NoteId = n.NoteId

您的Notes表可能类似于：

create table Notes
(
    NoteId int identity(1,1)
    ,NotesDetail varchar(max)
    // ... any other fields related to the Notes entity....
)

在其他表上，您只需要一个字段FK链接到Notes表上的NoteId。

Answer 5

我意识到这是旧的但是......

这将允许不止一个音符。

select n.NoteId, n.NotesDetail from Prospect p inner join Notes n 
on n.EntityId = p.id AND n.EntityType ='prospect'

为SQL中的许多实体表实现Notes表的最佳方法

5 个答案: