我有以下表格：

博客文章同时建模一个实体和一个关系，根据 6nf（根据第三个宣言）无效。

在 6nf 中，它将是：

如果我想按顺序排列博客文章 nbr（只是一个例子），那将是另一个表

我说的对吗？

我正在寻找有关如何实施第六范式的信息。我在网上到处搜索都没有成功。我想看一个如何实现和设计的例子。如果有任何关于如何实现它的书籍或文档，这将特别有帮助。

我正在创建一个数据库来存储很多事件。它们会有很多，它们每个都有一个精确到秒的相关时间。例如，像这样：

行动、来源和目标都在 6NF 中。我想保持Event表格标准化，但我能想到的所有方法都有问题。为了明确我对数据的期望，绝大多数（99.9%）事件将是唯一的，仅具有上述四个字段（因此我可以将整行用作 PK），但不能忽略少数例外.

1. 使用代理键：如果我使用四字节整数，这是可能的，但似乎只是无缘无故地夸大表格。此外，我担心长时间使用数据库并耗尽密钥空间。

2. 将计数列添加到事件：由于我希望计数较小，因此我可以使用较小的数据类型，这对数据库大小的影响较小，但在插入之前需要更新插入或汇集数据库外部的数据。其中任何一个都会增加复杂性并影响我对数据库软件的选择（我正在考虑使用 Postgres，它会进行 upserts，但并不乐意。）

3. 将事件分成小组：例如，同一秒内的所有事件都可能是 a 的一部分，Bundle其中可能有一个代理键用于组，另一个用于其中的每个事件。这为数据库增加了另一层抽象和大小。如果其他重复的事件变得普遍，那将是一个好主意，但否则似乎有点矫枉过正。

虽然所有这些都是可行的，但它们感觉不适合我的数据。我正在考虑只做一个典型的雪花而不是在主表上强制执行唯一性约束，但是在阅读了这样Event的PerformanceDBA 答案后，我认为也许有更好的方法。

那么，保持具有少量重复事件的时间序列数据归一化的正确方法是什么？

编辑：澄清 - 数据来源是日志，主要是平面文件，但也有一些在各种数据库中。该数据库的一个目标是统一它们。没有一个来源的时间分辨率比第二个更精确。这些数据将用于诸如“有多少不同的来源在时间间隔内对目标执行操作？”之类的问题。其中间隔不会少于一个小时。

当域是外键时，表是否满足 6NF？例如：

如果不是，模型应该如何处理外键关系？

而如果是M2M的关系，那应该怎么处理呢？连接表也应该是 6NF 吗？

对于一个简单的透视示例，SQL 代码是什么样的，其中有几个表处于第六范式？

很多人都在谈论使用 6NF 表如何轻松快速地进行旋转，但真的很难找到这样的例子。

可以说我有以下表格：

我将如何在不使用 MSSQL PIVOT 或同等产品的情况下进行旋转？说我想将成本与侧面的维度和沿列的月份进行汇总

介绍

我一直在阅读有关EAV 数据库的信息，大多数缺点似乎与非常非常糟糕的 EAV 设计或难以从数据生成报告有关。

通常，当您看到人们抱怨 EAV 时，他们使用少于三个表来尝试复制 RDBMS 中单独表 + 列的功能。有时这意味着将从小数到字符串的所有内容存储在单个TEXT值列中。EAV 还会扰乱数据完整性的保护措施，如果您不小心，这可能会非常糟糕。

但是，EAV 确实提供了一种简单的方法来跟踪历史数据，并允许我们在 SQL 和键值存储系统之间来回移动系统的某些部分。

如果我们根据类型区分不同的实体属性会怎样。除了与特定属性和实体相关的正确索引值之外，这将允许我们仍然处理 belongsTo、Has、HasMany 和 HasManyThrough 关系。

考虑以下两个基本实体

RDBMS 模式设计

众所周知，用户资料和产品是世界上最多样化的项目之一。每个公司对它们的处理方式不同，并且针对它们的需要有不同的“列”或“属性”。

以下是如何处理多个（嵌套和/或关系）实体的视图。

这个想法是，每个实体都有这个主属性表，然后指定如何查找和解释这些值。这使我们能够处理特殊情况，例如其他实体的外键以及“选项”或十进制数之类的东西。

entity_type { id, type, // 即“博客”、“用户”、“产品”等。 created_at }

像这样的表将允许我们永远不必这样做，UPDATE ...因为我们可以只INSERT INTO ...为每个更改值的新属性添加created_at以了解最新的值是什么。这非常适合保存历史数据的记录（当然仍然可以例外）。

示例查询

首先，它是什么“类型”的实体？（用户、帖子、评论等）

接下来，这个实体的属性是什么？（表属性）

接下来，该实体的属性中存在哪些值？（attr_### 表）

该实体存在哪些关系？

假设我们有一个 ID 为 34 的“post”实体，并且我们想要它的“comments”（entity_type = 2），这可以让我们获取产品实体上的评论实体 ID：

除了多个查询（无论如何都需要键值存储），这种方法会存在什么问题？

获取三层信息：

第 1 层：信息

该层包含具有UNIQUE自然索引的数据和易于传输的代理键。

自然键

或者，如 Mike Sherrill 所解释的，上面的两个表可以不ID使用 Surname 和 FirstName 作为自然主键。在这种情况下，假设下面的层引用varchar而不是int.

第 2 层：人

在这一层中，使用了复合索引。此值可以是UNIQUE或PRIMARY，具体取决于代理键是否用作主键。

第三层：父母

在这一层中，人们之间的关系是通过一个ParentsOf表格来探索的。

问题

假设引用完整性在其核心对我来说非常重要，并且我将拥有FOREIGN KEYS这些索引，以便我让数据库负责在这方面监控其自身的完整性，并且如果我要使用 ORM，它会像Doctrine一样，它具有对复合主键的本机支持......

请帮助我理解：

• 在第一层使用代理键与自然键时发生的权衡列表。

• 在第二层使用复合键与代理键时发生的权衡列表，可以转移到第三层。

我对听哪个更好不感兴趣，因为我知道专业人士在这个话题上存在重大分歧，这将引发一场宗教战争。相反，我非常简单和尽可能客观地问，通过将代理键传递给每个层与维护主键（自然/复合或代理/复合），您将采取哪些权衡。任何人都可以在 SO 和其他网站上找到说从不或总是使用代理键的人。相反，对权衡的合理分析是我在您的回答中最欣赏的。

编辑：有人指出，姓氏示例是使用 6NF 的不良示例。为了保持问题完整，我将保留它。如果您无法想象这个用例，一个更好的可能是“杂货项目”列表。又名：

自然复合键示例：

推荐配对

重申一下，这也只是一个例子。这不是我建议进行的方式，但它应该有助于说明我的问题。

这种方法存在不足之处。我要重申，这个问题是要求了解下面每种方法的优缺点，而不是强调其中一种方法比另一种更好。我相信大多数人都能够通过这个特定示例的可疑性质来回答核心问题。此编辑适用于那些不能。

下面有一些非常好的答案，如果您对前进的方向感到好奇，请阅读它们。

结束编辑

谢谢！

关于锚模型数据库设计中数据类型的问题。该问题假设锚模型实现与锚模型本身分离。

在 Anchor Model xml 中，我们有以下与数据类型相关的种类信息：

• dataRange="varchar(42)"
• identity="int"
• timeRange="datetime"

它们存储在锚模型实体（锚/属性）xml 节点中。
例子

据我了解，数据类型不会影响锚模型，它们会影响其对特定数据库供应商的实现。甚至历史属性的时间粒度也与模型无关。

所以问题是：

• 在元数据 xml 节点中存储数据类型信息不是更准确吗？因为它们不是模型的一部分
• 还是我遗漏了一些东西并且数据类型必须是锚模型的一部分？为什么？

以 MySQL 作为示例 DB 来执行此操作（尽管在此阶段我不限于关系风格）和用于模型/数据库交互的 Java 样式语法。

我希望能够在用户编辑对象时允许对各个列值（及其相应类型）进行版本控制。这主要是为了减少频繁编辑复杂对象所需的存储量。

一个简单的例子可能是

所以我们可以将一个对象插入到数据库中，看起来像......

给我们

如果我们想更新我们可能使用的权重

显然，尽管这将覆盖数据。

我可以在这个表中添加一个修订列，它可以随着项目的保存而增加，并设置一个组合 id/version 的复合键，但这仍然意味着为每个修订存储这个对象的所有属性

但在这种情况下，我们将存储关于每一项的每一条数据。如果用户对文本字段甚至 BLOB 数据可能是对象一部分的较大对象进行较小的修改，则这不是非常有效的。

我真正想要的是能够选择性地离散存储数据，因此权重可以单独保存在单独的数据库中，从而能够引用与其相关的表、行和列。

然后可以将其与表的 VIEW 一起粉碎，这可以将单个列数据的任何后续修订强加到混合中以创建最新版本，但无需为每个小修订存储所有数据。

不确定将任何数据作为 blob 存储到然后 CAST 回原始 DTYPE 可能有多成功，但我想既然我在这里发明了功能，为什么不发疯。

这种存储方法也相当危险，因为表名和列名完全可以更改，但希望这至少概述了我正在考虑的那种行为。

我有以下数据库模型

我首先使用 EF6 代码将我的实体映射到此数据模型

将 Entity 和 PropertyType 类映射到各自的表是直截了当的。EntityProperty 使用映射

如何根据哪个字段具有值将我的 EntityProperty 映射到PropertyValueString或表？PropertyValueDateTime此外，包含 EntityProperty 时生成的查询应该LEFT JOIN使用 PropertyValueString 和 PropertyValueDateTime。

这甚至可以使用实体框架吗？