我应该整合这些数据库表。

我与它后面的SQL数据库的事件日历应用程序，现在我有3个表来表示事件：我应该整合这些数据库表。

表1：假日
列：ID，日期，名称，位置，CalendarID

表2：假期
列：ID，日期，姓名，PERSONID，WorkflowStatus

表3：事件
列：Id，Date，Name，CalendarID

所以我有“通用事件”进入事件表和特殊事件，如假期和假期进入这些单独的表。我在辩论将这些内容整合到一张表中，并且只需将位置和personid这些列留空即可。

表1：事件：
列：ID，日期，名称，位置，PERSONID，WorkflowStatus

没有人看到任何强烈的积极或消极的每个选项。很明显，会有记录有不一定适用的列，但它与这三个表有重叠。

来源

2010-09-01 leora

我会合并 – 2010-09-01 01:18:08

无论采用哪种方式构建它，应用程序都必须应对变体类型。在这种情况下，我建议您在DBM中使用单一表示法，因为替代方法是要求多重查询。

因此，它成为一个问题，即你坚持复杂性的问题，即使在一个庞大的组织中，也很难生成足够的事件来担心DBMS优化。应用程序代码比硬连线模式更灵活。这是一个偏好问题。

来源

2010-09-01 01:21:04 msw

如果这是我的决定，我会把它们压缩成一张表。我会添加一个名为“EventType”的列，并在将数据导入到新表中以指定事件的类型时更新该列。

这样，你只需要索引一个表而不是三个索引（如果你觉得索引是必需的），那么这些数据都在一个表中，并且获取数据的查询会更简洁一些，因为你不需要将所有三张桌子结合在一起看看一个人做了什么。我没有看到将所有内容放在一张桌子上的任何缺点（尽管可能会有人提出，我没有想到）。

来源

2010-09-01 01:20:57

如果您需要将数据合并到一个结果集中进行使用，请将它们保存在3个独立的表中，并在视图中执行UNION ALL。只要性能足够，您将数据存储在磁盘上的方式不需要与您需要使用数据的方式相同。

就像你现在有没有列不适用于任何呈现的实体。如果要将3个表合并成一个表，至少需要添加一个字段以了解哪些列需要填充并降低性能。现在，当您单独查询假期时，您将访问必须筛选/ index的数据的子集以获取合并存储表中的相同数据。

如果您还没有定义这些表，您可以考虑创建一个具有以下签名的表格......

create table EventBase (
    Id int PRIMARY KEY, 
    Date date, 
    Name varchar(50) 
)

......并且，例如具有以下签名的假期表。

create table holiday (
    Id int PRIMARY KEY, 
    EventId int, 
    Location varchar(50), 
    CalendarId int 
)

......并在需要时加入两者。在这个和你已经拥有的3个独立表格之间进行选择取决于你如何计划使用表格和音量，但是我绝对不会把所有东西都放到一个表格中，并且让其他人看起来不那么清楚。引发。

来源

2010-09-01 01:24:57 Tahbaza

如何将特殊事件子类型输入为Event超类型？这样以后很容易就可以添加任何新的特殊事件。

alt text

来源

2010-09-07 12:24:24

您是如何产生ERD的？ – 2010-09-09 21:33:31

@Lese'ERwin Data Modeler' – 2010-09-09 22:38:42

或组合的共同领域，分离出独特的：

表1：EventCommon

列：EventCommonID，日期，姓名

表2： EventOrHoliday

列：EventCommonID，CalendarID，isHoliday

表3：价格

色谱柱：EventCommonID，PERSONID，WorkflowStatus

与1-> EventCommon和其他2.

来源

2010-09-07 16:49:05 Beth

数据之间一对多关系诚信是将他们放在一张桌子上的最大缺点。由于这些看起来都是需要的字段，因此您将无法默认要求所有字段，并且必须编写触发器以确保数据完整性得到正确维护（是的，这必须在数据库中维护，而不是，如有些人相信，除非你有数据完整性问题。）

另一个问题是，这些是你现在需要的事件，将来可能会有越来越多的专门事件，可能会破坏一种类型的事件的代码，因为您添加了另一个专门的字段，只适用于其他事情是一个很大的风险。当您修改以添加一些所需的假期信息时，您是否一定要检查它是否违反了有关假期的申请？或者更糟糕的是不会出错，但会显示您不想要的信息？你每次都要看实际的屏幕吗？对代码进行单元测试可能不会选择这种类型的东西，特别是如果有人愚蠢地使用select *或未能在插入中指定列。坦率地说，并不是每个组织实际上都有一个真正彻底的自动化测试流程（如果你这样做，可能会降低风险）。

我个人倾向于选择Damir Sudarevic的解决方案。所有常用字段的事件表（使得至少可以获取所有事件的列表变得容易）以及用于不共同保持的字段的专用表，使得编写仅影响一个事件并允许数据库维护的代码更简单它的完整性。

来源

2010-09-09 20:56:34 HLGEM

我应该整合这些数据库表。

回答

相关问题