我在破解他人的措施时候，我看到许多人把 SSN 或 ID 还曾被用做系列号，虽然尽量这么做是犯科的。并且人们也都知道这是犯科的，但他们已经习惯了。厥后，跟着偷取身份犯法案件的增加，我此刻的同行正疾苦地从一大摊子数据中把 SSN 或 ID 删除。
不要用用户的键
在确定回收什么字段作为表的键的时候，可必然要小心用户将要编辑的字段。凡是的环境下不要选择用户可编辑的字段作为键。这样做会迫使你采纳以下两个法子：
* 在建设记录之后对用户编辑字段的行为施加限制。如果你这么做了，你大概会发明你的应用措施在商务需求溘然产生变革，而用户需要编辑那些不行编辑的字段时缺乏足够的机动性。当用户在输入数据之后直到生存记录才发明系统出了问题他们该怎么想？删除重建？如果记录不行重建是否让用户走开？
* 提出一些检测和更正键斗嘴的要领。凡是，费点精神也就搞定了，可是从机能上来看这样做的价钱就较量大了。尚有，键的更正大概会迫使你打破你的数据和贸易/用户界面层之间的断绝。
所以照旧重提一句老话：你的设计要适应用户而不是让用户来适应你的设计。
不让主键具有可更新性的原因是在干系模式下，主键实现了差异表之间的关联。好比，Customer 表有一个主键 CustomerID，而客户的定单则存放在另一个内外。Order 表的主键大概是 OrderNo 可能 OrderNo、CustomerID 和日期的组合。不管你选择哪种键配置，你都需要在 Order 表中存放 CustomerID 来担保你可以给下定单的用户找到其定单记录。
如果你在 Customer 内外修改了 CustomerID，那么你必需找出 Order 表中的所有相关记录对其举办修改。不然，有些定单就会不属于任何客户——数据库的完整性就算垮台了。
假如索引完整性法则施加到表一级，那么在不编写大量代码和附加删除记录的环境下险些不行能改变某一笔记录的键和数据库内所有关联的记录。而这一进程往往错误丛生所以应该只管制止。
可选键(候选键)有时可做主键
记着，查询数据的不是呆板而是人。
如果你有可选键，你大概进一步把它用做主键。那样的话，你就拥有了成立强大索引的本领。这样可以阻止利用数据库的人不得不毗连数据库从而得当的过滤数据。在严格节制域表的数据库上，这种负载是较量精明的。假如可选键真正有用，那就是到达了主键的水准。
我的观点是，如果你有可选键，好比国度表内的 state_code，你不要在现有不能变换的独一键上建设后续的键。你要做的无非是建设毫无代价的数据。如你因为太过利用表的后续键[别名]成立这种表的关联，操纵负载真得需要思量一下了。
别忘了外键
大大都数据库索引自动建设的主键字段。但别忘了索引外键字段，它们在你想查询主表中的记录及其关联记录时每次城市用到。尚有，不要索引 memo/notes 字段并且不要索引大型文本字段（很多字符），这样做会让你的索引占据大量的数据库空间。
第 4 部门 - 担保数据的完整性