数据库设计问题

我有以下情况，想知道您的意见和投入。我的应用程序有一家公司。每个公司都有很多部门，而这些部门又有很多用户。我有一个日历在所有的水平。因此，公司有一个中央日历，每个部门有单独的日历，每个用户都有单独的日历。想法是当用户感兴趣的是在该公司的事件时，他/她可以将其添加到他们的calendar.Now，我需要有一个或events.I很多表在想是否数据库设计问题

我应该有一个表，这将有一个字段来唯一标识每个实体（公司，部门，用户），并根据谁查询，我可以检索结果相应
我应该有多个表。公司一张，部门一张，一张。

所以它更像是有一张桌子对着三张桌子。

感谢

来源

2010-07-06 felix

谢谢你的所有输入。我将分成多个表格。再次感谢:) – felix 2010-07-07 15:47:42

查看应用程序的要求 - 如果为不同级别的事件在本质上是相同的（具有相同的数据需求，行为），你应该只使用一个表。如果他们会有所不同，请使用不同的表格。

来源

2010-07-06 05:58:16 Oded

这将是相同的领域。但是如果只有一个表，当我查询时它会影响性能，因为我将有更多的记录来查询，我会经常查询它们。 – felix 2010-07-06 05:59:48

@Steve - 您对此有何期望？每周有数百万条记录？一年？十年？ SQL服务器可以处理数百万条记录而不会出现问题，只要您已正确索引表并对性能进行调整即可。 – Oded 2010-07-06 06:05:19

我不认为事件需要知道他们是否属于公司，用户部门直接。我会怀疑事件属于公司，部门或用户的日历和日历？

所以日历表：

CALENDAR_ID

然后事件表

EVENT_ID

和一个 “EVENT_TO_CALENDAR” 表（用于多对多关系的目的：

CALENDAR_ID 
EVENT_ID

如果用户可以在公司日历中看到事件，他们可以说“添加到我的”，这将创建一个新的记录器d在EVENT_TO_CALENDAR表中，具有相同的EVENT_ID但唯一的CALENDAR_ID。该事件现在链接到每个日历（公司和用户的）。

来源

2010-07-06 05:58:59

+1可用性。看起来像我最优雅的解决方案。 – 2010-07-06 07:41:59

我想我会争取三张桌子。首先，如果你选择一个表，它将得到三个可为空的外键。这意味着您不能仅仅保证数据库模型的一致性，但您必须在业务逻辑的某个位置保证它的一致性。其次，随着时间的推移，您很可能会发现公司日历与员工或部门日历略有不同。例如，后者可能需要额外的列。你无法预测这一点。

来源

2010-07-06 06:01:44

在Oracle中，您可以添加需要填充COMPANY_ID，DEPT_ID和PERSON_ID中只有一个的检查约束。同样，可以设置约束来验证公司特定的属性是否已填充。 – 2010-07-06 15:08:27

数据库设计问题

回答

相关问题