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

13 浏览
0 Comments

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

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

TABLE Human(
    int humanId PK,
    string name
);

和：

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

此外，还有一组“动作”。对于每个动作，必须定义它是否适用于给定的角色。

TABLE Action (
    int actionId PK,
    string title
);

示例元组可能是：

Human ( 78asd7, "Bob");
Animal ( fgh7df, "Dog", "Pluto");
Action ( d6guvs, "Eat");
Action ( hj5j6f, "Check_Self_Awareness");

如何实现一个人和一只狗都能“吃”，但只有人可以“自我意识检查”？

我看到两种可能性：

A）通过外键解决：n:m表`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") {
    // 继续执行
}
if (type of DB_Tupel == "Animal" && action.title == "Check_Self_Awareness") {
    // 错误：动物没有自我意识（除了猿类）
}

你会推荐哪种方法？

0

2 答案

0 Comments

数据库设计-通过外键进行多少逻辑？

在忽略你具体的例子之前，我认为这不是你问题的重点，你正在询问是否使用表驱动逻辑还是硬编码逻辑。

对于这个问题，没有简单的答案。其中一个并不总是比另一个更好，每个方法都有优点，使其适用于特定情况。

表驱动逻辑在规则结构相对简单且一致的情况下很有用，但规则的具体情况事先不知道或可能经常更改。

在你的例子中，新的动作可能会定期产生兴趣。当这种情况发生时，你想要做什么？你想要在你的ACTION表中插入一行新数据，还是想要去修改所有的IF/ELSE语句？

硬编码逻辑在规则结构是静态的情况下很有用，尤其是当规则非常复杂时。将算术的优先顺序驱动通过表格并没有太多意义，因为它们不会改变，并且不适合被表驱动。

每种方法都是一种技术。你的目标应该是编写可靠、清晰、可支持的代码。在每种情况下选择最适合帮助你实现这个目标的方法。

如果你理解关系模型，并且它是基于一阶逻辑的，那么你可能会明白所有数据都可以，并且应该以数据的形式在FOL谓词中定义。由于数据库是一个事实的集合，不存在不能以FOL的形式在数据中声明的事实。"硬编码逻辑"是违反关系模型、开放架构和其他标准的行为。

0
0 Comments

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

数据库设计中的外键逻辑是由标准要求的。根据标准，数据库需要定义数据以及规定数据的所有规则来保证数据的完整性和一致性。这不是一种滥用，而是必需的。数据库是一个可恢复的单个单元，规则和事务随数据库一起传输。

“通过外键有多少逻辑？”这个问题实际上并不是逻辑，而是数据定义，包括规定数据的规则和完整性。此外，除了通过外键之外，还有很多其他方法来定义这些规则。

将数据规则实现在代码中不仅是次标准的做法，而且会产生一个只能通过应用程序访问、没有完整性的文件系统而不是数据库的情况。大多数用户希望能够通过任何报表工具来访问数据库，而不仅仅局限于应用程序。

一些理论家和面向对象/ORM支持者撰写了关于如何实现原始的、1970年代前的ISAM记录文件系统以及大量对象堆栈（实际上是塔）的书籍，并将它们标记为“关系型”。他们只知道这些，只能教授这些。

由此产生的结果是，由于记录文件系统无法做任何事情（不能做这个，不能做那个，不能支持层次结构等等），并且由于将记录文件系统标记为“关系型数据库”，他们认为关系型数据库不能做这个、那个和其他的事情。

因此，如果要获得一个关系型数据库，即在定义术语上类似于1970年的数据库，实现术语上类似于1984年的数据库，则需要在数据中实现有关数据的规则。

ID字段将使您完全依赖于1970年代前的ISAM文件，其中包含记录而不是具有行的表。ID是物理记录指针，而不是逻辑键。它们没有键的特性，也不能提供关系键所提供的完整性。

ID字段不符合关系模型中定义的键的定义，使用SQL关键字PRIMARY KEY不能使字段变为键。

如果要在一句话中陈述关系型和非关系型数据库管理系统之间的区别，那就是在非关系型数据库管理系统中，关系是通过物理记录ID建立的，而在关系型数据库管理系统中，关系是通过逻辑关系键建立的。

因此，使用ID字段作为建立关系的方法无疑是非关系型、物理、非逻辑和原始的。

而且，每个ID字段（列意味着表，它们是文件而不是表）都会建立一个访问路径依赖性，这在关系模型中是明确禁止的。这保证了更多的连接，而不是根据神话所说的减少连接。

为了获得关系型数据库、保证关系完整性、提高性能和速度，您需要关系键和关系标准化。摒弃ID字段，选择自然键。然后，在子表中，这些键将被合并。这是关系型数据库的标准做法，所有SQL平台都可以处理。适应它。

所谓的“滥用”其实是正常的参照完整性。这只是最简单、最基本的层次。关系完整性远不止于此，但它从这个最基本的层次开始。

要获得关系型数据库，您的表将是这样的。目的是演示关系键。为了演示关系完整性（RFS无法提供），我需要至少三个层次。

那是一个IDEF1X模型。IDEF1X是自1993年以来用于建模关系型数据库的标准。请注意，每个小刻度、缺口、标记、乌鸦脚、实线与虚线、方形与圆角都具有非常具体和重要的意义。如果您不理解符号，就无法理解或使用该模型。

与IDEF1X不同，UML不仅不是一个标准，而且它只有一个符号和一个无数不断变化的符号，并且它不能像关系数据建模标准那样定义数据或数据关系的复杂性。它根本没有这种丰富性。相反，您根本不知道您错过了什么。

标准要求的。标准的好处就是有这么多可供选择。

0