========= 此场景下，该选择关系型数据库还是NOSQL? =================

[愚者只看星不看答案]

有点长，请保持一点耐心。

业务场景：
系统需要用户可以自定义各种表单，然后收集各表单中输入的数据。假设现在有三种业务(实际中有哪种业务完全未知)
1、信用卡办理，要求提供 常住地址，婚姻状况(已婚 1，未婚 2，离异 3),房产信息(自有无贷款，租房，按揭)
2、带宽开户 要求提供 开户地址，速率(4M,8M)
3、婚姻登记 要求提供 男女方姓名，出生日期

由于需要的业务类型及需要的字段完全未知并且相同的业务，如婚姻登记在不同的时期需要收集的信息完全不同，例以后可能需要新增一个婚检状况的字段，
而带宽开户以后可能并不需要选择速率
基于此，所以不能按传统的关系数据库那样设计表(我并不希望通过编程的方式来创建相同类型但有着不同字段的表),
那么当前我的想法是在表中nvarchar(max)列上保存上述表单收集来的JSON

表结构(SQL Server)：
create table test
(
id int identity(1,1) not null,
order_id int not null,
total_price decimal not null,
is_complete bit not null,
json_data nvarchar(max) not null
);

表数据可能是这样：
1 1 25.0 1 {"常住地址":"","婚姻状况":1,"房产信息":"租房"}
2 2 45.5 0 {"开户地址":"","速率":"4M"}
3 3 22.4 0 {"男方姓名","","女方姓名":"","男方出生日期","","女方出生日期":"",}


在SQL Server 2016中，为了提高在json_data列中保存的JSON数据的查询速度，可以通过创建一个依赖于JSON某属性值的计算列，然后再在计算列上编制索引

假设这里为了提高信用卡办理业务中的婚姻状况的查询速度，那么相应的表结构将是

create table test
(
id int identity(1,1) not null,
order_id int not null,
total_price decimal not null,
is_complete bit not null,
json_data nvarchar(max) not null,
婚姻状况 as cast(json_value(json_data,'$.婚姻状况') as int)
);

这里创建婚姻状况计算列，它的值来源于信用卡办理业务中的JSON数据的婚姻状况属性值
再在婚姻状况上创建索引

这样可以仅仅可以提高特定查询的速度，而且婚姻状况的计算列对于其它业务类型来说毫无意义，最重要的是，我不能再接着创建 速率,房产信息这样的计算列来提高查询的速度,更何况查询也有由用户定义出来的。


我对于NOSQL了解的并不多，请问此种场景下，是不是更适合于NOSQL来解决此类问题。多谢。

[愚者只看星不看答案]

up............

[rucypli]

果断mongodb

[愚者只看星不看答案]

引用 2 楼 rucypli 的回复:

果断mongodb

哈哈，感谢你分享你的经验给我。。多谢。

[ckc]

不同类型的数据存放在一张表里意义不大，更别说你还有查询统计的要求。 按我的看法，应该建立3张表存放这些数据，用关系型数据库

[qq_36362642]

up............

[ckc]

就我的观点，业务发生变化表结构进行微调是很正常的事情，并不是什么完全不能接受的 你的重点在哪里？是查询速度？是系统开发速度？维护成本？

[愚者只看星不看答案]

引用 5 楼 ckc 的回复:

不同类型的数据存放在一张表里意义不大，更别说你还有查询统计的要求。 按我的看法，应该建立3张表存放这些数据，用关系型数据库

感谢回复。。你的建议看起来并不可行，你可以再阅读下上面的需求。。

[my_bot]

mongoDB 最好的选择 像 婚姻情况 ,常住地址,房产信息 有就写,没有就不写

[学无止境-逆流而上]

可以用Mongodb来设计，但不是你理解的json，而是内嵌document。json作为文本概念，要做查询什么的，必须走全文检索，显然2中数据库都不适合。而mongodb内嵌document方式是可以满足的，你应该有一份全局字典，对应的是你保存进document中key对应的业务字段。比如cardAddress:信用卡常住地址，用于页面展示等。你可以了解一下mongodb的内嵌document概念。