探讨企业级应用中，如何允许用户增加自定义字段

我所说的用户增加自定义字段，是指最终用户可以通过配置等手段，可以在界面上增加各种类型的想要的字段，这个字段可以用来存储和查询。

例如：有一个客户信息表，原来只有名称和地址，客户想自己添加，生日，分类，地区等字段。
添加完的字段要达到:
1）能保存
2）能查询
3）能用来排序
4）能用来分组统计

我所见到的做法，一般都是通过表里预留字段来做得，例如cust01,cust02等，各种类型都预留一些，一种是直接增加了另一张表，比如xxxx_ext表，里面有大量的cust01,cust02等。

这样作的缺点是，
1）数量是固定的，一旦某个类型的字段，我要添加一大堆，就可能碰到限制了。
2）可读性很差，看数据库的时候，会看到一堆不知道是什么东西的数据，还要找对应关系。不知道能不能把这些字段和字段表述做成视图呢？
3）扩展表的方法会多做一次join，影响效率。

我考虑是不是还有其他的方法。
1）是否可以使用XML。所有自定义的数据都写到XML里面，然后利用数据库提供的XML功能。我不了解数据库提供的XML功能，请有经验的朋友解答一下。
2）和上面类似，使用一个text字段。不过内容可以用其他的格式，比如yaml或者json。比上面的优点是占用空间小了。然后写个函数，专门从里面根据字段名取数据，然后基于这个函数作查询，排序，分组。
3）能不能用动态的DDL，或者自动生成rails的migration，然后停机升级。

不知道大家都是怎么作的？有没有更好的方案？

强调一下,我说的情况是,你把程序开发完了,交给客户,需要给客户提供一个可以自定义字段的功能,然用户增加一些他想要的字段,这个过程中开发人员不再参与.
大家说自己的方案的时候,最好能够简单描述一下优缺点.

评论

49 楼 cloudeye 2009-12-02  

理论上，采用META表可以解决自定义字段的问题。（META表是多加了一层抽象：管理元数据的元数据）
但这将带来很多的编码量。（因为要自己写META表访问的DB接口，某种意义上，你在写一个数据库软件）性能也要打个问号。

而在程序上实行DDL查询实在是一个不好的办法－－维护数据库将是噩梦。

考虑具体情况，如果自定义字段只是特例不是普遍的数据存储要求，有时候采用预留字段的方式是最快最好的办法。

48 楼 dazuiba 2009-12-01  

一个破问题讨论到现在。

最懒的方式是去redmine看看人家咋着做的。 直接拷贝到你项目里面就行了。

人家已经抽出了个customable之类的东西， 简简单单Include一下就O了

47 楼 archangel 2009-11-30  

但是对于不同类型不同表的方案我有点不理解，这样做这样也许存储效率是提高了，但是统计怎么做？还有这样会给开发带来的额外劳动应该也不少吧。

46 楼 archangel 2009-11-30  

动态字段这样的需求在软件项目基本不应该存在，如果真的出现了，那么预期提前做这样的设计，还不如改程序来的直观，所以也会有人说是不能答应的需求之一。

但是对于软件产品，这样的需求很常见也很有用，因为你永远不知道下一个客户需要的字段是什么样的。

45 楼 ferly_j 2009-02-01  

请问写在xml里的,如果要更新岂不是要重启服务器?
这个热加载问题怎么解决?

44 楼 vtrtbb 2009-01-20  

这种问题很常见，尤其是做OA或者ERP系统时候。
其实你组织好数据字典就行了，把所有的描述都放到你定义好的表里，然后自己开发底层程序对这些表进行操作，最好再开发一个客户端的小工具来维护这些表就可以了。

我曾经开发过一个系统，只要你在excel表里配置好数据后，然后通过自己编写的工具导入到服务器数据库中，系统基本就可以跑了，类似于一个开发体系，开发一个系统的时候，只要用这个平台基本的东西都可以搭建起来，而且用户也可以自定义表单。。
比如说：有个学籍表，今天客户突然想加个“本人成分”的选项，他自己就可以完全完成，不需要像以往那样，由程序员来数据库里家字段，修改po之类的东西，修改页面。。。。

43 楼 sacred02 2009-01-20  

赞同caicai_45的思路，使用行转列再加个视图，应该能比较好的解决这个问题。

42 楼 csc365kl 2009-01-19  

业务逻辑的复杂的产品最好不要太追求可配 而是 可维护 可重构 提供服务的接口定义是最重要的 一定要定义好 如果你是想做一个 配置下今天可以变成美食网 明天改下配置又能变成体育网的 可配应用 你就用纵表吧

41 楼 caicai_45 2009-01-13  

嘿嘿，我09年年初的时候，可能也要做一个类似的项目，大概的需求和LZ的是一致的。

数据库的设计思路是这样的，行列转置。

每个实体的属性的存储，是放到一行记录中的，类似这样Product表设计
ProductID  Name  ProductType
1          MP3   消费数码

行列转置，采用类似key-value的方式来做
Product表，就一个ProductID 字段，然后有一个 ProductField表，
ProductFieldID FieldName  FieldType
1              Name       string
2              ProductType string

然后有一个关系表 Product_Field
ProductID  ProductFieldID value
1          1              MP3
1          2              消费数码

这样如果Product增加一个属性的时候，在ProductField中新增一条记录即可。
同时在对应关系中增加 一条 对应关系的记录。

这样既能满足基本的查询，扩展性也是一个提高。但是只能做到查询和显示，如果涉及到业务逻辑要根据这些字段来决定走向，基本不可能。

40 楼 wuxiaoq 2009-01-13  

Jackphone 写道

微软的Access都用过吧，想想它是怎么实现的。

这就像做一个DB Client，不过这种需求倒是让我觉得很奇怪，客户是想自己开发吗？

客户是想省银子。。。

39 楼 木哥哥 2009-01-13  

xiaoyu的:多类型表多值

form_rr的:多值多类型

这2个人说的都很好啊

原来你们2个说的是一样的....刚才误解了......

xiaoyu的是全都是固定表;

form-rr的是有一个固定（模板）表+一个不固定表;

数据结构都是以key-value来表示。

38 楼 Jackphone 2009-01-07  

微软的Access都用过吧，想想它是怎么实现的。

这就像做一个DB Client，不过这种需求倒是让我觉得很奇怪，客户是想自己开发吗？

37 楼 qamer 2009-01-07  

新建一张表，每条记录对应一个自定义字段，一张关系表记录字段的内容

36 楼 pekkle 2009-01-04  

java 有什么key-value好的模型吗？
xiaoyu说的key-value不太明白

35 楼 shuai45 2009-01-04  

个人感觉一下：
实现来说不是问题,应该很容易。写xml也好,存数据库也好 都没问题。但效率和性能是考虑最主要的问题。
1如果写成xml文件。应该说写入非常便捷。但要满足查询，搜索或者其它 在实现起来效率不稳定，而且也难于维护。如果用户的数量多，相对的xml文件也应该不少。频繁的对硬盘操作不是件好事。
2写到数据库。写到数据库问题也不大，而且写到数据库后对于查询 修改 删除也非常方便。但面临的问题是性能和效率。用户反复的连接数据库,对数据库进行操作，而这些功能其实可有可无的东西，所以如果为满足这样的需求而单独建表，还要去维护有些得不长失。
3写到内存。通过第三方的存储空间来时间也是个办法。写到内存中通过K和V来定位。但如果数据量大的话性能和效率也一样。

     所以个人认为 写到数据库中应该可以。前提是 数据库必须经过优化 最好写存储过程 而且处理的时候减少不必要的数据连接 给予适当的连接释放。
      

34 楼 sofar1218 2009-01-02  

不停机？ 这个怕是过分了

33 楼 laochake 2008-12-31  

自定义表，国内估计有不少人在搞
把开发人员都解放了，只要实施人员就可以了
想法是很不错，但就是折腾人，成功几率很低

32 楼 Scriptlet 2008-12-31  

2楼是正解。cms系统就是用来存储用户定义的数据，所以很有参考性

31 楼 feilng 2008-12-30  

用户从来不关心字段，都是技术导向的沟通导致的

30 楼 feilng 2008-12-30  

真正的企业级用户不需要自己增加自定义字段