AdventureWorks有插入/更新/删除异常？

AdventureWorks表具有插入/更新/删除异常。这是不是认为糟糕的设计？AdventureWorks有插入/更新/删除异常？

以下表为例。

Sales.SalesReason(SalesReasonID, Name, ReasonType, ModifiedDate)

其中ReasonType是类型为nvarchar（50）

我们不应该有ReasonType另一个表因此模型是这样的：

SalesReason(SalesReasonID, Name, ReasonTypeId, ModifiedDate) 
ReasonType(ReasonTypeId, Name)

这样做的更新时， ReasonType的名称只能在一条记录上进行更改（防止更新异常）。此外，它将通过保留db中的可用类型来防止删除/插入异常，而不管是否存在与它们相关的实际数据。

我可以对此事有你的想法吗？

来源

2012-03-05 poke

将ReasonType移除到其他表不会改善任何内容。据推测，每个ReasonType仍然会有一个ReasonTypeId，因此您仍然可以执行相同数量的更新。我想你假设你需要更新ReasonTypeId的次数比ReasonType少。在不了解业务需求的情况下，这只是一种可能性，但与解决数据库设计理论通常关心的“更新异常”类型无关。

从归一化理论的角度考虑表格。如果依赖关系是：

{SalesReasonID}->{Name} 
{SalesReasonID}->{ReasonType} 
{SalesReasonID}->{ModifiedDate}

，如果SalesReasonID是唯一的关键，则表已在第五范式。所以它不需要进一步的分解。

The Relational Database Dictionary有这样说的术语“更新异常”：

一个有点老土来看，都不是很精确的定义，对于这样的事情可以去错在不到完全规范化数据库

卡罗Zaniolo说：

ANOM的没有明确的说明在不知道用户设想的操作的情况下可以给出alies

（ACM Transactions on Database Systems， 6，No.1，1981年3月）

来源

2012-03-05 07:20:26 sqlvogel

感谢您的回答。我不确定你是否正确理解我，可能我不是很清楚。让我们拿这个数据为例： SalesReason： '（1，“Name1”，“Some Reason”，1/1/2001），（2，“Name2”，“Some Reason”，6/5/2001），（3，“Name3”，“Some other reason”，7/6/2001），（4，“Name4”，“Best Reason”，8/9/2001）' – poke 2012-03-05 15:40:39

所以，我想改名“有理由”改为“有全新名字的原因”。为了做到这一点，我必须做两行更新。这是一个简单的例子，但可以说我有其他具有ReasonType列的表。如果我把它当作一个外键，那么我只需要在ReasonType表上更新该单个记录上的名称。此外，仅仅通过查看数据库，我并不真正知道什么是可用的和可能的原因类型。你对此有何评论？ – poke 2012-03-05 15:40:46

刚刚发现一个主题，支持声明，AdventureWork有异常，请看看：[http://stackoverflow.com/questions/4824024/how-important-are-lookup-tables](http://stackoverflow.com/ question/4824024/how-important-are-lookup-tables） – poke 2012-03-05 18:24:45

AdventureWorks有插入/更新/删除异常？

回答

相关问题