例如,假设我们有一个应该包含事务类型的字段,可能的值是Sale,Return,Service和Layaway.我将创建一个包含代码和描述的事务类型表,使代码可以是“SA”,“RE”,“SV”和“LY”,并使用代码字段作为主键.然后在每个交易记录中我发布该代码.这比记录本身和索引中的整数键占用的空间更少.究竟如何处理它取决于数据库引擎,但它的效率不应低于整数键.而且因为它的助记符很容易使用.您可以转储记录并轻松查看值是什么,并且可能记住哪个是哪个.您可以在用户输出中显示没有翻译的代码,用户可以理解它们.实际上,这可以使您获得超过整数键的性能提升：在许多情况下,缩写对用户有利 – 他们经常需要缩写来保持显示紧凑并避免滚动 – 因此您不需要加入事务表得到一个翻译.

我绝对不会在每条记录中存储长文本值.就像在这个例子中,我不想放弃交易表并存储“Layaway”.这不仅效率低下,而且很可能有一天用户会说他们希望将其改为“Layaway sale”,甚至是“Lay-away”之类的微妙差异.然后,您不仅需要更新数据库中的每条记录,而且还必须在程序中搜索此文本发生的每个位置并进行更改.此外,文本越长,程序员错误拼写并创建模糊错误的可能性越大.

此外,具有事务类型表提供了存储有关事务类型的附加信息的便利位置.永远不要写代码说“if whatevercode =’A’或whatevercode =’C’或whatevercode =’X’然后……”无论是什么使得这三个代码与所有其他代码有所不同,请为它在事务表中并测试该字段.如果你说“嗯,这些都是与税收相关的代码”或其他什么,那么很好,创建一个名为“tax_related”的字段,并根据需要为每个代码值设置为true或false.否则当有人创建新的事务类型时,他们必须查看所有这些if /或列表,并找出应该添加哪种类型以及不应添加哪种类型.我已经阅读了很多令人困惑的程序,我必须弄清楚为什么某些逻辑应用于这三个代码值而不是其他代码值,当你认为第四个值应该包含在列表中时,很难判断它是否是失踪,因为它在某种程度上是真的不同,或者如果程序员犯了错误.

我没有创建转换表的唯一类型是当列表非常短时,没有其他数据需要保留,并且从宇宙的性质可以清楚地看出,它不可能永远改变,因此值可以安全硬编码.像真/假或正/负/零或男/女. (嘿,即使是最后一个,看起来很明显,有人坚持我们现在包括“变性”之类的东西.)

有些人教条地坚持每个表都有一个自动生成的顺序整数键.在许多情况下,这样的键是一个很好的选择,但对于代码列表,我更喜欢短阿尔法键,原因如上所述.