程序界面设计之--在数据库有一行多个列代表属性改为直接多列代表登记属性的程序信息录入设计是否可行欢迎讨论？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 3112 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近在设计一个质检系统录入产品信息的界面，输入字段包括：[报告 id],[报告编码],[报告状态],[承检机构],[收样日期],[检验类别],[入库日期] ,[检验流程] ,[型号规格],[样品类别],[样品等级],[样品名称],[生产单位],[样品数量],[计量单位]等等信息。
这些信息要求可以调整顺序及可以增加自定义字段，比如后期用户想在输入界面增加一个,[委托单位] ,[存放位置],[单位地址]用户可以通过前台直接增加。

前期我本来准备把所有需要的信息都放到一行来输入，直接数据库 select * from [登记表] 就可以取到所有的登记信息。但是后期增加字段太不方便。
就想用多行来代表输入的信息，在录入的时候选取所有输入字段，每个报告 id 有多个输入字段，后期可以随意增加输入字段，也可以修改输入字段的显示文字及显示顺序。
但现在我所接触的程序好像都是按一行多个列名来设计的，只接触过在一个学生成绩统计程序里面一个学生对应多个功课分数时才把结果设计为多行数据。
想问问大家这样设计有什么缺点，可以这样设计不？另外有没有其他设计方式，数据采用 mssql 数据库。
下图为设计方式截图
如何上传图片？一会在上传图片

输入

样品

设计

字段

7 条回复 • 2016-05-29 08:07:18 +08:00

yocoso

2016-05-28 04:09:36 +08:00

我花了 5 分钟看你的问题，没看懂，我放弃了。
如果你想问的是：
1. 一个表拥有这些固定项：
[报告 id],[报告编码],[报告状态],[承检机构],[收样日期],[检验类别],[入库日期] ,[检验流程] ,[型号规格],[样品类别],[样品等级],[样品名称],[生产单位],[样品数量],[计量单位]
2. 还需要根据用户需求增加一些额外信息，额外信息不定
3. 可以调整字段在 UI 上的顺序
那么我的回答是：
1. 竟可能的明确固定项，如果[委托单位] ,[存放位置],[单位地址]是将来某些产品会需要的信息，那么就把它作为单独一个字段。
2. 如果实在有现在没想到的，将来一拍脑瓜子出现的。有两种方式解决：
a. 新增一张表
b. 这张表新添一个字段叫做 extra ，里面存键值对比如 {拍脑瓜子想出的字段：不是很重要的信息，不小心发现我们还需要这个信息：那就存在这里把}
3. 关于字段的显示顺序，可以纯 UI 上实现。但如果想记住调整的顺序的话，得再用一张表来存。

chaegumi

2016-05-28 07:14:00 +08:00

http://simpleframework.net/news/view?newsId=a8aea83fc76540908138c3b995c99094

saulshao

2016-05-28 08:44:14 +08:00

纵向表(A-V 对)和横向表(常见的表)之间的区别，从逻辑上看其实不大，但是所有的关系数据库系统都是基于列来进行查询、索引、主外键等操作，因此，横向表在性能上优势明显。 @yocoso 的回答我完全赞同，应该尽量确保能确定的字段放在横向表，如果实在是要考虑扩展，可以使用纵向表。

heeryuy

2016-05-28 09:32:50 +08:00

也可以参照一些 CMS 系统的做法，自定义添加一列时同时直接在数据库里面增加对应的列，这样还能对自定义列做查询

qile1

2016-05-28 18:42:29 +08:00

@yocoso 非常感谢回复，就是你理解的，我主要想请教在输入界面如何灵活控制输入的内容，及顺序，实现用户自动调整显示顺序，调整项目是否显示。
比如用户不想显示,[样品类别],[样品等级]或者用户想调整这两个项目的显示顺序，设计如三楼那样的横向表，就很费力实现用户的需求。
而使用纵向表设计，
可以直接控制显示名称，是否显示，显示顺序，但是在大数据量的时候查询好像不太好查询。
@heeryuy 在数据库自己增加一列还是一行？如果把表直接增加一列需要修改表结构了吧?这样也可以？

yocoso

2016-05-29 02:20:51 +08:00

@qile1 我觉得针对质检产品信息这个应用场景，需要记录的项目应该是有数的，不会天马行空突然多一些不着边际的字段。还是设计成横向表。需要增加新字段就新增一列，不是分布式数据库的话，这个就是改一个 schema ，很简单。

tftk

2016-05-29 08:07:18 +08:00

使用了 EAV 模型，你将失去很多数据库提供的方便之处，包括不限于强制属性存在，引用完整性，
多查询一个字段，就要多 join 一次表，等等。
这种情况可以很方便的使用 PostgreSQL 的 JSON 类型解决。