一个表还是多个表，用于许多不同但相互作用的事件？

一个表还是多个表，用于许多不同但相互作用的事件？ V1.0

在对数据进行组织和规范化时，关系数据库和SQL（专为它们而设计）的性能要好得多。就性能和关系能力而言，一个大表是未规范化的，并且已经瘫痪了。

您的需求需要一个普通的表的Supertype-Subtype集群。不幸的是，像这样的普通关系结构并不“常见”。

• 标准子类型符号是半圆。

  • Supertype :: Subtype的基数始终为1 :: 0–1。

  • 子类型主键是超类型主键。它也是超类型的外键。

• 有两种类型：

  • 排他性，每个超类型行只有一个子类型，用半圆X表示。

  • 非排他性，每个超类型行中有一个以上子类型

• 您的专属。此类型需要一个鉴别器，以标识超级类型行中哪个子类型处于活动状态。如果子类型的数量少，则可以使用指标；否则，需要分类表。

• 请注意，所有这些，结构，规则，约束，支持它以及提供数据完整性所需的信息都可以在普通的IEC / ISO / ANSI SQL中获得。（非SQL不符合SQL要求）。

数据

1. 命名非常重要。建议我们按行命名表格，而不要按内容，含义或动作命名。您说的是活动，但我只能看阅读。

2. 这些阅读或事件必须有上下文。我看不到EventId如何悬空。我假设阅读材料是针对特定患者的。请指教，我将更改其型号。

3. 复合键或复合键是正常的。SQL非常有能力（非SQL没有）。

   PatientId

   已经作为FK存在于中

   Reading

   ，并用于形成其PK。不需要 额外的

   ReadingId

   列和 额外的索引 ，这将是100％冗余的。

4. SQL还具有处理许多表的能力（我正在处理的数据库目前超过500个表），关系数据库的本质是大量较小的表。

5. 这是纯第五范式（没有重复的列；没有更新异常）。

   • 可以将其进一步归一化为第六范式，从而可以获得进一步的好处；并且可以优化6NF等。但这里并不需要所有这些。

   • 有些表恰好在6NF中，但这是结果，而不是意图，因此不能这样声明。
     。
     

6. 如果您提供有关您所关注的限制和替代的信息，我可以提供解决这些问题的模型。

7. 由于对数据 进行了 建模，因此已经将其设置为非常快速的比较（生成警报等）。