========= 此场景下，该选择关系型数据库还是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来解决此类问题。多谢。

9 个解决方案

#1

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

#2

果断mongodb

#3

引用 2 楼 rucypli 的回复:

果断mongodb

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

#4

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

#5

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

#6

引用 5 楼 ckc 的回复:

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

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

#7

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

#8

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

#9

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