下面，我将解释我正在处理的数据库的基本设计。因为我不是数据库，所以我担心如果我处于良好的轨道或糟糕的状态，所以我想把它放在堆栈上以获得一些建议。我无法找到符合我设计的类似讨论。
在我的数据库中，每个表都被视为一个实体。实体可以是客户账户，个人，用户，一组员工信息，承包商信息，卡车，飞机，产品，支持票等。以下是我当前的实体（表格）......
为了存储有关这些实体的信息，我有两个表：
Entity Tables
-EntityType
-> EntityTypeID (INT)
-Entities
-> EntityID (BIGINT)
-> EnitityType (INT) : foreign key
我创建的每个表都有一个自动生成的主键，以及一个entityID列上的实体表的外键。
在实体表中，我有一些共享字段，如
我在所有表上使用触发器在插入时自动创建具有正确实体类型的实体条目。更新触发器会更新LastModified日期。
从应用程序层的角度来看，所有代码所要做的就是担心各个实体（USER_Modified / User_Created字段＆＃34除外;它通过加入entityID对它进行更新＆＃34; < / p>
现在，实体表的原因在于我计划拥有EAV模型，因此每个实体类型都可以使用自定义字段进行扩展。它还可以作为存储有关实体的元数据的合适位置（如创建/修改的字段）。
我对数据库设计不熟悉，并希望获得第二意见。
答案 0 :(得分：2)
我计划拥有一个EAV模型，因此每个实体类型都可以使用自定义字段进行扩展。
为什么呢？ 所有您的实体是否需要以这种方式扩展？可能不是 - 在大多数应用程序中，最多只有一个或两个实体可以从这种灵活性中受益。其他实体实际上受益于 not 一直在变化的稳定性和清晰度。
的一个示例内部平台效应是设计一个可定制的系统的结果，它最终成为它所设计的平台的糟糕复制品。
换句话说，现在您有责任编写应用程序代码来执行正确的RDBMS已经提供的所有内容，例如约束和数据类型。即使是像NOT NULL这样强制使用列这样简单的事情也无法在EAV中使用。
有时候项目需要大量的表格。但是如果你认为通过只制作两个表来简化项目，那么你就是在愚弄自己。你仍然会拥有与桌子一样多的不同实体，但现在由你决定不让它们变成一堆垃圾。
在你投入太多时间进入EAV之前，请阅读这个关于一家几乎停止运作的公司的故事，因为有人试图让他们的数据存储库任意灵活：Bad CaRMa。
我还在一篇博文EAV FAIL和我书中的一章SQL Antipatterns: Avoiding the Pitfalls of Database Programming中写了更多关于EAV的文章。
答案 1 :(得分：1)
你还没有真正给出设计。如果您已经给出了表的描述，那么面向应用程序的标准将针对每个行的行进入时间以及随后的约束（包括键，fks等），以及涉及您的实体的应用程序部分，那么您将给出部分设计。换句话说，如果你已经给出了那部分直截了当的关系设计。 （仅仅因为你没有以这种方式实现它并不意味着你不需要正确设计。）请注意，这必须包括应用程序级别的状态和功能，以便随着自定义进行扩展字段＆＃34 ;.但是，你必须给出一个表的描述，一行中每一行的标准以及随后的约束，包括密钥，fks等，用于通过EAV编码前一部分的实现部分，以及操作它们的操作符。换句话说，如果你已经给出了那部分直截了当的关系设计。您的设计部分是implementing a DBMS。然后你真的会给出一个设计。
人们需要使用EAV＆＃34;因此每个实体类型都可以使用自定义字段进行扩展＆＃34;是错的。只需通过有时更新元数据表的调用来实现，而不仅仅是更新常规表：DDL而不是DML。