数据库设计:支持抽象或外键约束?

And*_*ech 1 language-agnostic oop database-design entity-relationship

假设我们有这种情况:

Artist ==< Album ==< Track
//ie, One Artist can have many albums, and one album can have many tracks
Run Code Online (Sandbox Code Playgroud)

在这种情况下,所有3个实体都具有基本相同的字段:

  • ID
  • 名称
  • 与相应孩子的一对多关系的外国人(艺术家到专辑和专辑跟踪

提供的解决方案的典型解决方案是三个表,具有相同的字段(ArtistID,AlbumID等...)和一对多关系字段中的外键约束.

但是,在这种情况下,我们可以采用一种继承形式来避免重复同一个领域吗?我说的是那种:

Table: EntityType(EntityTypeID, EntityName)
       This table would hold 3 entities (1. Artist, 2. Album, 3. Track)

Table: Entities(EntityID, Name, RelField, EntityTypeID)
       This table will hold the name of the entity (like the name of 
       an artist for example), the one-many field (foreign-key
       of EntityID) and EntityTypeID holding 1 for Artist, 2 for Album 
       and so on. 
Run Code Online (Sandbox Code Playgroud)

您对上述设计有何看法?在此DB场景中合并"OOP概念"是否有意义?

最后,您是否更喜欢第一个场景的外键约束或更通用(例如,将艺术家与Track连接的风险,因为没有检查输入器外键值是否真的是一张专辑)方法?

..btw,想到它,我想你实际上可以检查一个艺术家的RelField的输入值是否对应一个专辑,可能有触发器吗?

cdo*_*ner 5

我最近看到了这种抽象概念的实现,并且应用程序及其数据库成为了维护和排除故障的怪​​物.我会远离这种技术.更简单,更好,是我的口头禅.