从你所描述的内容来看,这听起来像是jsonb的工作。假设 name 在某张桌子上是独一无二的,我可以这样想象:
name
create table test ( tableId integer, name text, data jsonb, constraint pk primary key(tableId, name) ); insert into test values (1, 'movie1', '{"rating": 10, "name": "test"}'); insert into test values (1, 'movie2', '{"rating": 9, "name": "test2"}'); insert into test values (2, 'book1', '{"rank": 100, "name": "test", "price": 10}'); insert into test values (2, 'book2', '{"rank": 10, "name": "test", "price": 12}');
基本上,我们的想法是使用tableId来标识每个子表,并在这个db表中存储子表的行。
这开启了一些可能性:
create index test_1_movie_name on test ((data->>'name')) where tableid = 1
我在你的问题中看不到任何会阻止你使用具有相应数据列数的普通表。这是最有效的存储形式 的 到目前为止 强> 。最小的存储大小,最快的查询。
表是 “一旦创建就永远不会更新,但可能会被过滤” 几乎没有“动态”。除非你隐瞒必要的细节。
除非可以有超过100列。看到:
(但你后来评论最多12个,这根本不是问题。)
动态列意味着 的 架构较少 强> 是我们应该寻找的选择。 MongoDB是首选。我们存储为JSON吗?如果是这样,Mongo将帮助操纵数据/提取/报告将使生活更轻松。
如果您不熟悉NOSQL。 MSSQL 2016以上列中的JSON存储支持为varchar(MAX)。 SQL Server提供了处理JSON数据的功能。即使它默认为nvarchar的基于文本的索引。 SQL支持基于计算列的索引,这将有助于处理JSON中的元素。允许任意数量的非聚集索引计算列,这将简化索引以处理JSON数据。 SQL 2019对JSON有更多支持