sql – 其他字段实体的最佳DB结构

前端之家收集整理的这篇文章主要介绍了sql – 其他字段实体的最佳DB结构前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我在DB(基于Postgres)中有一个表,它在面向对象编程中就像一个超类.它有一个列’type’,用于确定表中应存在哪些附加列(子类属性).但我不希望表包含所有可能的列(所有可能类型的所有属性).

所以我决定制作一个表,包含’key’和’value’列(即’filename’=’/ file’,或’some_value’=’5′),其中包含对象的任何可能属性,不包括在内在超类表中.并且还创建了一个相关表来包含可用的“键”值.

但是这种架构存在问题 – 默认情况下,’value’列应该是字符串数据类型,以便能够包含任何内容.但我不认为转换成字符串是一个很好的决定.绕过此限制的最佳方法是什么?

解决方法

您正在尝试的设计是 Entity-Attribute-Value的变体,它带来了很多问题和效率低下.除了作为最后的手段之外,这对你正在做的事情来说不是一个好的解决方案.

什么是更好的解决方案是fallen888描述的:为每个子类型创建一个“子类型”表.如果你有一个有限数量的子类型,这听起来就像你拥有的那样,这是可以的.然后,您的子类型特定属性可以具有数据类型,如果合适,也可以是NOT NULL约束,如果您使用EAV设计,这是不可能的.

子类表设计的另一个缺点是你不能强制在子类表中存在一行只是因为超类表中的主行说它应该.但这比EAV设计引入的更为温和.

编辑:关于您对任何实体的评论的其他信息,是的,这是一种非常常见的模式.谨防一种称为“多态关联”的破解解决方案,这是许多人在这种情况下使用的技术.

猜你在找的MsSQL相关文章