在您的问题中，我看不到任何东西可以阻止您使用具有相应数据列数的普通表。这是迄今为止最有效的存储方式。最小的存储空间，最快的查询速度。
“创建后从不更新，但可能被过滤”的表很难是“动态的”。除非你隐瞒了重要的细节。
除非有超过100列。请参见：
postgresql select查询中的最大列数是多少
（但您后来最多评论了12条，这完全没有问题。）

从你描述的情况来看，这听起来像是jsonb的工作。假设 name 在某张table上是独一无二的，我可以想象这样的事情：

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

动态列意味着无模式是我们应该寻找的选项。首选mongodb。我们是否存储为json？如果是这样的话，mongo将帮助处理数据/提取/报告将使生活更轻松。
如果您不熟悉nosql。mssql 2016以后的json列存储支持varchar（max）。sqlserver提供了处理json数据的函数。尽管nvarchar默认是基于文本的索引。sql支持基于计算列的索引，这将有助于处理json中的元素。允许任何数量的非聚集索引计算列，这将简化处理json数据的索引。SQL2019对json有更多的支持