我现在对我的项目的这一点,我需要设计我的数据库(Oracle) . 通常,对于status和countries表,我不使用数字主键
STATUS (max 6)
AC --> Active
DE --> Deleted
COUNTRIES (total 30)
UK --> United Kingdom
IT --> Italy
GR --> Greece
这些表是静态的,不是通过应用程序更新的,并且预计将来不会进行更改,因此在使用这些值作为外键的表中不存在更新问题 .
该应用程序的主要表格将使用状态和国家(不止一次,例如来自原籍国,目的地国家),预计每年将增加600000行
所以我的问题是,当查询3个表的连接时,这些VARCHAR(2)密钥是否会对性能产生影响 . 第一个会明显慢于第二个吗?
SELECT m.*,
s.status_name,
c.country_name
FROM main m, status s, countries c
WHERE m.status_cd = s.status_cd
AND m.country_cd = c.country_cd
AND m.status_cd = 'AC'
AND m.country_cd = 'UK'
SELECT m.*,
s.status_name,
c.country_name
FROM main m, status s, countries c
WHERE m.status_cd = s.status_cd
AND m.country_cd = c.country_cd
AND m.status_cd = 1
AND m.country_cd = 2
澄清:
状态不是二进制(表名旁边是“最大6”) . 值可能是:
* active
* deleted
* draft
* send
* replaced
我们需要向用户显示解码值,因此我们需要名称 .
4 回答
状态和国家表都非常小,无论是否正式陈述,它们都将成为实际的记忆驻留者 . 实际上,除了外键通常需要在引用的主键字段上使用索引之外,您可能不想打扰表上的任何索引 .
不同类型的连接之间的性能差异可以忽略不计,并且数字代码将会更慢,因为存储的“更多”数据(但它是如此之小以至于可以忽略不计) .
所以,请使用自然代码 . 除此之外,第一个例子中的SQL更清晰; '英国'和'AC'比1和2更有意义 .
在非Oracle DBMS中,您可能会将CHAR(2)用于状态和国家/地区代码值 . Oracle用户倾向于使用VARCHAR2来处理所有事情;我不确定使用CHAR(2)列是否会受到惩罚,特别是因为列值是固定长度 . (例如,在Informix下,VARCHAR(2)字段 - 最多两个字符的字段 - 将存储为3个字节,长度(在您的情况下总是2)和2个数据字节 . 相比之下,CHAR(2) )字段只占用2个字节 . )
看看这个link . 底线是varchar和num之间没有太大的性能差异 . 因此,您应该选择对该列有意义的内容 . varchar似乎更有意义 .
如果'status'是(并且将永远是?)二进制活动/删除字段,为什么还要打扰表 . 似乎规范化被带到了一个不切实际的极端 .
简单地使用tinyint(1)字段并将活动/删除状态记录为1或0肯定会更快,更不用说更容易了 .
这完全消除了你的一个连接,这必须是一件好事 .
在这种情况下,您选择哪种方法无关紧要 . 重要的是在整个数据库中使用相同的类型,并在您的id约定中保持一致 .