关系数据库学的最重要的一个理论是：不要给关键字赋予任何业余意义。假如关键字具有了业务意义，当用户决定业务含义，也许他们想要为关键字增加几位数字或者把数字改为字母，那么就必须修改相关的关键字。一个表中的主关键字有可能被其他表做为外键。就算是一个简单的改变，也可能会造成极大的维护上的开销。
为了使表的主键不具有任何业务意义，一种解决办法是使用代理主键，例如为表定义一个不具有任何业务含义的ID字段（也可以叫其他名字），专门做为表的主键。
我回顾我以前设计的很多数据库，都在某些地方没有考虑周到，即使大部分的主键都没有业务意义，还是会有某些表的主键和业务联系起来。因为我一直认为，主键是用来保持唯一性的，之所以要有代理主键，是因为有一些记录的内容没办法保持唯一性。例如设计一个用户表，用户的名字有可能重复，这个人可能叫blue，那么人也可能叫blue。这样就需要一个ID来分清。
由于我之前的想法，导致我数据库设计上的一些错误。例如我曾经在一次数据库设计中使用一个ID来做为一个表的主键，该表是记录一些报表的。每个报表上都有一个ID，这个ID是具有业务意义的，是可以让客户输入，也可以自动生成的，但是客户说明这个ID是唯一的，是数字类型。因此由于它的唯一性，我在数据库中设计这个ID为数字类型的。但是到了后来客户要求使用文字类型的，例如原来的是“111111”，他要求可以写成“11111A”，“11111B"。这个时候由于这个ID做了很多表的外键，就会产生很多维护上面的麻烦。即使在数据库表之间做了级联更新和级联删除，修改数据类型还是很麻烦的事情。
这次RFID项目数据库设计我原来想使用RFID标签的ID做为产品的主键，因为RFID标签ID具有唯一性，使用它作为主键在查找的时候速度应该会快些。但是后来发现问题并不是这么简单。如果使用RFID标签ID做为主键，那么就具有了业务意义。当产品表和其他表关联，产品表的主键做为其他表的外键的时候，如果出现一些业务上的情况，例如RFID标签坏了，要更换，就会产生更改主键内容的问题了。
回顾一下，还是发现自己的基础不扎实。学习数据库的时候都不去上课。少年不努力，老大徒悲伤。