请教设计数据库字段冗余好不好？

[happy2003]

这几天在做数据库设计，有设计到表的字段，如 性别字段，学历 这种枚举值，有的同事认为为了查询和开发方便，设计2个字段，一个代表ID，一个代表具体的枚举值
这样的设计不知道，好不好呢?这几张表，目前规划数据量可能在千万条左右

我觉得这样设计
优势：
1方便平时的查询
2 提高程序查询的速度
3 方便面向对象的方式开发

缺点：
1 不太方便维护数据，如果
处理不好，容易造成数据不一致现象。
2 插入数据的时候，性能稍低
3 数据库存储空间将有增加
4 会对现有程序进行修改，有一定的工作量，主要在存储的时候增加存储字段和查询的时候不在join表

[Andy__Huang]

不好，在实现数据一致性上会让花出更大代价。

[hokor]

满足第三范式。
单独设计一张表，设计2个字段，一个代表ID，一个代表具体的枚举值。
ID为主键，与其他表做外键关联。

[永生天地]

其实没有必要做这样的表。
根据实际情况看。如果是枚举的值很少，而且固定不变，直接在表里设计

比如性别这个，根本不需要为他建表，直接在用到的表里设计一个字段

sex 在说明里写上 0-男，1-女，就完了，或者干脆就直接存 男 女

何苦弄得 那么麻烦，

[duanzhi1984]

我觉得没必要,说不好听点，有点多余。

虽然数据库方面的书籍说满足第三范式，但实际工作当中，冗余的现象很多。
我所维护 的数据库有的时候还必须故意冗余以满足查询速度 快的需要。


面对固定的性别，真的是没必要的。要么用1,0表示，在显示的时候以CASE 判断，要么直接 以男女即可。

[happy2003]

顶一下

[obuntu]

枚举值的，就不用这么麻烦了，直接存储。

[SQLCenter]

3
4
有理

[feilniu]

如果这个枚举值比较简单，可以只存一个字段，如性别字段只存0/1、男/女、M/F都可。
如果这个枚举值需要包含更多的信息，比如不同性别决定不同的休假策略，不同学历决定不同的薪酬策略和人力资源开发策略，那最好有一个单独的性别表、学历表，其它表只存这两个表的主键来表示性别、学历。

千万不要在一个表里“设计2个字段，一个代表ID，一个代表具体的枚举值”。范式固然不是必须遵守，但这个地方完全没有违反范式的理由。否则，“在实现数据一致性上会让花出更大代价。”

[obuntu]

有种东西叫“反范式”，理论是死的，以实际为准。