头痛的自定义字段设计

实体表：
entity {
id //唯一编号
...//其他固定的属性
}
属性表：
attribute{
id //唯一编号,
name //属性名称,
type //属性类型 比如：数字，文本，列表，日期等,
remark//描述
}
属性值：
attributeValue{
id,属性值的编号
entityId,实体对象编号
attributeId,属性编号
orderIndex,属性的顺序
value属性值
}
--------------------
粗略设计一下，你可以改进

建议看下 magento 系统的 实现,

嗯，已经在看了。我现在就是在分析它的设计是否适合大数据量的查询与统计。

有一种做法是定义一组元数据表，称为metadata，里面保存的不是业务字段，而是表和字段的信息

然后根据元数据，生成业务表，真实的信息保存在业务表里

这部分如果不是查询条件的话，可以做成 Key value  的方式，用于显示。维护修改都很方便。

所谓修改表结构存在性能问题，是因为修改时有可能锁表。很多DDL语句会阻塞DML语句。但是这并不是绝对的，在大型企业数据库中哪些表结构修改会造成阻塞哪些不会都是有文档的。而且绝大多数修改是可以申请到窗口期的，基本上很难想象连这点窗口期都申请不到。
用户随意修改表结构是否合理要看业务需求，不过总的来说除非灵活过度，一般情况下怎么也是一个相对稳定的状态。如果真的灵活频繁到极致，那么也就不是关系数据库的菜了，至少不是关系理论本身的问题了，需要启用数据库中的XML或者JSON扩展，甚至可能更加适合NoSQL数据库。

感谢啊！
我最后差点连预留字段都想使用了。因为用前面网友说的magento的eav模式我觉得不合适。虽然说它的灵活度很好。但是生成的这些字段都参与业务，如查询统计等。这样效率方面肯定受影响。
NoSql我也考虑了一下。它就比较适合我的要求，但是又有一个问题，它没事务，不能回滚。这样又让我们有更多的考虑。

有得必有失，框架和技术的选择是各方面权衡的结果。现代的关系数据库技术这几年发展同样很快，原来很多必须停机停业务才能做的事情现在在线就可以做。各种优化自动化技术也都在发展，让关系数据库仍然是软件开发存储的第一选择，现在虽然NoSQL发展很快，但是除了互联网公司，如果不是特别需求，还都尽量在关系库中考虑。
至于NoSQL的事务问题，因为各种原因肯定和关系数据库的事务不是一个概念，需要进行专门的调整。这方面你可以去问具体产品的支持社区，事务问题大家肯定也都有所考虑，应该都有方案，至于是否合适你就要看具体情况了。

自定义字段是可以做的，关键问题是现有系统支持自定义字段的话需要对原有系统进行改造。比如对新增加的字段进行查询。
这个技术上是可以实现的，上家公司一个系统就有这个东西，原因是广电系统好多字段要动态添加，需求不停变，所以好好架构这个功能是可以做到的。

另外，这种方案对性能有影响，互联网项目谨慎使用。