Question

这是关于数据库设计的理论问题。我可以“滥用”关系作为数据库中的条件，或者我可以在源代码中使用传统的if条件。我将尝试用一个例子来解释我的问题：让我们假设我们有两个代理字符（伪代码）：

TABLE Human(
    int humanId PK,
    string name
);

和

TABLE Animal(
    int animalId PK,
    string species,
    string name
);

此外，还有一系列“行动”。如果可以为给定角色使用，则必须定义每个动作。

TABLE Action (
    int actionId PK,
    string title
);

示例Tupels将是

Human ( 78asd7, "Bob");
Animal ( fgh7df, "Dog", "Pluto");

Action ( d6guvs, "Eat");
Action ( hj5j6f, "Check_Self_Awareness");

我如何实现人类和狗都可以“吃”，但只有人类可以“Check_Self_Awareness”？

我看到两种可能性：

A）通过外键解决：n：m tables HumanActions和AnimalActions 即。

TABLE HumanActions (
    int humanId FK,
    int actionId FK
);

HumanActions ( 78asd7 , d6guvs);
HumanActions ( 78asd7 , hj5j6f);

TABLE AnimalActions (
    int animalId FK,
    int actionId FK
);

AnimalActions ( fgh7df , d6guvs);

B）在代码中解决它

if (type of DB_Tupel == "Animal" && action.title == "Eat") {
    // continue
}
if (type of DB_Tupel == "Animal" && action.title == "Check_Self_Awareness") {
    // error: animals don't have self awareness (except for apes)
}

你会推荐什么？

Answer 1

建筑与建筑标准

好吧，伟大的E F Codd博士（祝福他的名字）在1970年写了关系模型;自1984年以来，我们拥有真正的SQL平台;开放式架构自1987年以来，作为自1990年以来的标准。所以答案不仅仅是我的建议，不仅仅是最佳实践，而是标准要求。 IE浏览器。期望存在超过几年的组织要求。

原则是在数据库中将数据定义为数据，包括管理数据的所有规则。这是完整性和一致性所必需的。这不是一种滥用＆＃34;。该数据库是单个可恢复单元。规则和交易随数据库一起传播。

外键有多少逻辑？

它不是逻辑＆＃34;。它是数据定义，管理数据的规则及其完整性。除了简单地使用外键之外，还有很多很多方法。

非架构＆amp;子标准

＆＃34;数据规则在代码中实现＆＃34;它不仅是不合标准的，而且它产生的文件系统而不是数据库，没有完整性，只能通过应用程序访问。那不是＆＃34;封闭的架构＆＃34;，这是非架构。比时代晚了四十五年。大多数用户想要访问数据库而不限于应用程序，例如。通过数百种报告工具中的任何一种。

但是后Codd＆＃34;理论家＆＃34;谁声称要服务于这个行业，以及OO / ORM类型，写关于如何实现原始的，关系前的，1970年以前的ISAM记录文件系统的书籍，以及大量的对象（塔，真的）没有后哥德关系数据库的完整性，速度或能力，并标记它们＆＃34;关系＆＃34;。这就是他们所知道的一切，这就是他们所能做到的所有＃34;。

结果是，由于RFS无法做任何事情（不能这样做;不能做到这一点;不能支持等级制度等等），并且因为RFS是标记为＆＃34;关系数据库＆＃34;，他们认为关系数据库无法做到这一点，而另一件事。无价的。

因此，如果你想要一个关系数据库，大约在1970年定义的术语，大约1984年的实现术语，那么在数据中实现有关数据的规则。

HumanAction是Human的孩子
AnimalAction是Animal的孩子

记录ID

ID字段可以很好地粘贴到1970年代以前的ISAM文件，包含记录，而不是包含行的表。 ID是物理记录指针，而不是逻辑键。它们不具有Key的特性，并且它们无法提供Relational Keys提供的完整性。

它不对参数开放，因为根据关系模型中的定义，ID字段不符合Key的条件。使用SQL关键字PRIMARY KEY并不能在场上赐予Key的质量。
如果要说明关系型和关系型前DBMS之间的区别，用一句话来说就是：

在关系前DBMS关系是使用物理记录ID 建立的，但在关系DBMS关系中是使用逻辑关系密钥建立的。

因此，使用ID字段作为形成关系的方法，无疑是前关系型，物理的，非逻辑的，原始的。
此外，每个ID字段（列暗示表，它们是文件，而不是表）建立访问路径依赖性，关系模型中明确禁止。根据神话，这可以保证更多的连接，而不是更少的连接。

为了获得关系数据库，为了获得关系完整性，功能和速度，您需要关系密钥和关系规范化。摆脱ID字段，并选择自然键。然后，在子表中，键将被复合。这是RDB的标准票价，所有SQL平台都处理它。习惯它。

模型

这是一款IDEF1X型号。自1993年以来，IDEF1X是关系数据库建模的标准。请注意每个小刻度;缺口;并标记;乌鸦脚;实线与虚线;广场与圆角;意味着非常具体和重要的东西。请参阅IDEF1X Notation。如果您不理解符号，您将无法理解或工作模型。

UML，与它分开不是一个标准，与它分开，只有一个单一的符号和一个千万亿不断变化的符号，与它分开是事实上的自由，不能定义数据或数据中关系的复杂性，如标准关系数据建模可以。它根本没有丰富性。相反的是，你根本不知道你缺少什么。

拒绝

如果您不喜欢这条消息，请拍摄信使。善意，九十九。除了（a）证明拒绝我所暴露的问题已达到病态水平，（b）证明马戏团怪人的奴役，（c）明天将有另一名使者。

Answer 2

忽略您的具体示例，我不认为这是您的问题的重点，您在询问是否使用表驱动逻辑或硬编码逻辑

这个问题没有简单的答案。一个并不总是优于另一个，每一个都有优势，使其适合特定情况。

表格驱动逻辑在您的规则结构相对简单且一致时非常有用，但您的规则的详细信息事先未知或可能经常更改。

在您的示例中，可能会定期对新操作感兴趣。发生这种情况时你想做什么？是否要在ACTION表格中插入新行，或者是否要触摸所有IF/ELSE语句？
当规则的结构是静态的时，或者当规则非常复杂时，
硬编码逻辑非常有用。启动算术运算顺序的表格不会有很大意义，因为它们不会发生变化，并且它们不适合用于表格驱动。

每种方法都是一种技术。你的目标应该是可靠，清晰，可支持的代码。选择最能帮助您在每种情况下实现目标的方法。

数据库设计 - 外键有多少逻辑？

2 个答案:

建筑与建筑标准

非架构＆amp;子标准

记录ID

相关数据

模型

拒绝