希望开发新功能 按照分类信息字段进行帖子主题的排序

楼主真是想要开发人员的老命哟～

1、分类信息有多种字段类型，有些类型排序无啥意义，比如‘邮件’，‘单选radio’。有些类型无法排序，比如‘图片’，‘多选checkbox’。有些无法直接排序，比如‘日历’类型dz普遍使用timestmp int4类型来保存日期而并未使用timestamp/date字段类型。所以程序先得判断字段是否可排序，然后还可能要为排序字段做类型转换。

2、分类信息的表结构方式为：每个分类信息类别对应一个数据表 比如 cdb_optionvalue25。 25为此分类信息类别的id来至于 cdb_threadtypes 表（此表既保存主题分类类别也保存分类信息类别）。如果要对单个分类信息字段进行排序至少涉及两个表的关联查询，而分类信息值保存在两个地方 cdb_typeoptionvars 和 cdb_optionvaluesID，前者以TEXT类型的value字段保存所有分类信息值（比如int类型的年龄），后者以字段方式保存所有int类型的分类值（但没有除int类型之外的，比如姓名、地址就不在此表中）。在编辑帖子的分类信息时会同时对这两个表进行更新（dz72可以编辑，貌似DZX2.5不能编辑帖子中分类信息值）。
好吧后者是所有可排序字段的表，那么逻辑走向如下：
cdb_threads.sortid  (--> cdb_typevars.optionid) --> cdb_typeoptionvars
于是问题又来了，DZX2.5的新构架那么多代码就为实现表分服务器以及拆分表关联查询为多表单独查询，可是排序字段是不可能实现表拆分而必须在一条SQL中执行，这岂不辜负了开发人员的心血嘛～

此时的SQL复杂度大大增加，不但必须多表关联，而且查询/关联字段是多个（至少有fid，sortid），排序字段即不是前面的字段也不是主键而是它表一个不定字段，在这个表中一个tid可有多条记录（对应不同的分类信息项）但因为只能通过sortid而无法用optionid关联所以因此还需要做GROUP BY。
天，即便dz开发人员卧薪尝胆给你做出来了，mysql也会撂挑子的！

总的来说，许多功能不是做不到而是无法在弱智的mysql实现。随着功能的增加，SQL查询数据之间逻辑关系复杂度的增加，对于一个非关系型数据库（RDBMS）的mysql来说将是一个噩梦。了解的人会明白 NOT IN与 EXCEPT/MINUS之间性能差别会有多大。对于discuzX来说随着功能模块的增加，数据间关联度的越发紧密使得SQL查询连表数量越来越多（mysql子查询性能一直被诟病）。而X2.5新构架的目的就是通过拆分表连接为单表查询来提升数据库性能，这又与连表查询的实际需要背道而驰。结果是程序代码搞得臃肿不堪而实际上数据库性能也并未有多大提升——对性能影响大的SQL往往就无法拆分。

所以这么纠结的根源就在mysql上面：系统的功能模块发展对于数据库处理关系（relationship）的能力要求越来越高，而mysql确不是真正的关系型数据库。于是什么新构架，新优化，硬件升级无非是给mysql补窟窿而已，把本该由数据库高效率完成的任务交给其他“人”来低效率完成。此时的费效比是相当低的。
还是那句话： mysql是最昂贵的免费数据库。

ok,好了，有人回答吗，分类信息字段才最有用。

这个对网站性能有挑战