Ant*_* F. 8 postgresql database-design foreign-keys jsonb
我正在考虑将PostgreSQL的jsonb
列类型用于新的后端项目,该项目主要用作REST-ful JSON API.我相信PostgreSQL jsonb
将非常适合这个项目,因为它将为我提供JSON对象而无需在后端进行转换.
但是,我已经读过,jsonb
添加密钥时数据类型会变慢,而我的架构需要使用主键和外键引用.
我想知道是否在自己的列中使用主键/外键(以标准的关系数据库方式),然后jsonb
为其余数据创建列将是有益的,否则会导致问题(无论是现在还是未来) ?
简而言之,会:
table car(id int, manufacturer_id int, data jsonb)
Run Code Online (Sandbox Code Playgroud)
表现更好或更差:
table car(data jsonb)
Run Code Online (Sandbox Code Playgroud)
特别是在经常查找外键时?
从性能或架构的角度来看,第一个会有缺点吗?
Erw*_*ter 13
a PRIMARY KEY
或FOREIGN KEY
约束中涉及的所有值必须存储为专用列(最好采用标准化形式).约束和引用不嵌套值工作中一个json
/ jsonb
列.
至于其他数据:它取决于.将它们置于jsonb
(优选地)值内具有存储非结构化文档类型数据的众所周知的优点和缺点.
对于存在于所有行或大多数行的属性,将它们作为单独的列存储将更可能更好(更快,更清洁,更小的存储).索引更容易,查询也更简单.即使新功能jsonb
具有惊人的索引功能,索引专用列仍然更简单/更快.
对于很少使用或动态显示的属性,或者如果要在数据库内部进行大量处理而存储和检索JSON值,请查看jsonb
.
对于主要使用字符数据的基本EAV结构,没有嵌套并且没有与JSON的连接,我会考虑hstore
.还有xml
(更复杂和冗长)和json
数据类型(大多数被取代jsonb
),它们正在失势.
归档时间: |
|
查看次数: |
4773 次 |
最近记录: |