我没有做过正式的研究，但根据我自己的经验，我猜测超过 80% 的数据库设计缺陷是由于将性能作为最重要（如果不是唯一）考虑因素而设计的。
如果好的设计需要多个表，请创建多个表。不要自动假设连接是应该避免的。它们很少是性能问题的真正原因。
在数据库设计的所有阶段中，首要考虑的因素是数据完整性。 “答案可能并不总是正确的，但我们可以很快给你”并不是任何商店都应该努力实现的目标。一旦数据完整性被锁定，如果性能成为问题，可以解决。不要牺牲数据完整性，尤其是为了解决可能不存在的问题。
考虑到这一点，看看你需要什么。您有需要存储的观察结果。这些观察结果的属性数量和类型可能有所不同，可以是测量值、事件通知和状态变化等，并且有可能添加未来的观察结果。
这似乎符合标准的“类型/子类型”模式，其中“观察”条目是类型，每种类型或观察种类是子类型，并建议某种形式的类型指示符字段，例如：
create table Observations(
...,
ObservationKind char( 1 ) check( ObservationKind in( 'M', 'E', 'S' )),
...
);
但是在检查约束中硬编码这样的列表的可维护性水平非常低。它成为架构的一部分，只能使用 DDL 语句进行更改。这不是您的 DBA 所期待的。
因此，在自己的查找表中包含各种观察结果：
ID Name Meaning
== =========== =======
M Measurement The value of some system metric (CPU_Usage).
E Event An event has been detected.
S Status A change in a status has been detected.
（char 字段也可以是 int 或smallint。我在这里使用 char 进行说明。）
然后用 PK 和所有观察结果共有的属性填写观察结果表。
create table Observations(
ID int identity primary key,
ObservationKind char( 1 ) not null,
DateEntered date not null,
...,
constraint FK_ObservationKind foreign key( ObservationKind )
references ObservationKinds( ID ),
constraint UQ_ObservationIDKind( ID, ObservationKind )
);
在 Kind 字段和 PK 的组合上创建唯一索引可能看起来很奇怪，它本身就是唯一的，但请耐心等待。
现在每种类型或子类型都有自己的表格。请注意，每种观察都会获得一个表，而不是数据类型。
create table Measurements(
ID int not null,
ObservationKind char( 1 ) check( ObservationKind = 'M' ),
Name varchar( 32 ) not null, -- Such as "CPU Usage"
Value double not null, -- such as 55.00
..., -- other attributes of Measurement observations
constraint PK_Measurements primary key( ID, ObservationKind ),
constraint FK_Measurements_Observations foreign key( ID, ObservationKind )
references Observations( ID, ObservationKind )
);
前两个字段对于其他类型的观测值是相同的，除了检查约束将强制该值为适当的类型。其他字段可能在数量、名称和数据类型方面有所不同。
让我们检查一下Measurements 表中可能存在的示例元组：
ID ObservationKind Name Value ...
==== =============== ========= =====
1001 M CPU Usage 55.0 ...
为了使该元组存在于该表中，观察表中必须首先存在 ID 值为 1001 且观察类型值为“M”的匹配条目。 ID 值为 1001 的其他条目不能存在于观察表或测量表中，并且根本不能存在于任何其他“种类”表（事件、状态）中。这对于所有类型的表都以相同的方式工作。
我还建议为每种观察创建一个视图，它将提供每种观察与主观察表的连接：
create view MeasurementObservations as
select ...
from Observations o
join Measurements m
on m.ID = o.ID;
任何仅处理测量的代码都只需要访问此视图而不是基础表。使用视图在应用程序代码和原始数据之间创建一堵抽象墙，大大增强了数据库的可维护性。
现在，创建另一种观察（例如“Error”）涉及到 ObservationKinds 表的简单 Insert 语句：
F Fault A fault or error has been detected.
当然，您需要为这些错误观察创建新的表和视图，但这样做不会对现有的表、视图或应用程序代码产生影响（当然，编写新代码来处理新观察的情况除外） 。
