关于设计数据库几个思考

 混过几个公司，看过经理设计的数据库，本人同时不才也设计过几个系统的数据库(几十张表的系统),自感设计表时及其痛苦，在了解需求业务之下，开始建表，但心中老是浮现大学学过的数据库设计三范式，每次用powerdesiger设计时，口中振振有词，“设计三范式，设计三范式，设计三范式”，有时更是为了遵守范式而设计，甚是苦恼，不经意之间，多了几份疑问，到底如何建表，百度谷歌，更多的是理论，理论，理论，复制粘贴。

 

问一：

三范式要遵守吗？

   几个公司，有家公司经理三范式遵守的非常厉害，很少发现冗余，当然俺在那里面开发代码甚是很累，显示个东东都要做下关联查询，我的个神，一张表到处都是外键，有时查询相当的慢，只有通过存储过程，或者view视图，而有的公司，设计完全不遵守，想到哪里，设计哪里，发现不想做外键，就蛋炒饭给表加字段，结果主表那个冗余啊，想当年，跟老板讨论过关于三范式问题，老板说我被教条害了，为了提高速度，减少关联，改冗余还是得冗余，痛定思痛后，又是一番百度谷歌，我总结了这么个办法，比如企业表(企业id,城市id)，城市表(城市id，城市名称，邮政…..)，往往客户希望看到企业同时需要城市名称，那么我这样设计企业表(企业id,城市id，城市名称)，城市表(城市id，城市名称，邮政…..)，问题来了，每次维护企业城市，得小心了，大家懂的，这样符合界面开发，当需要详细城市时，给个弹出框，但问题来了，三范式去哪儿了，违法了啊，这是一问。

问二：

    外键何去何从？

为什么提到外键，被惠普问过，他奶奶的，我说我建表从来不做外键，结果被教导了一番，甚是苦恼，目前从事的公司，没有任何一家数据库设计建了外键，见与不见，百度谷歌那是舌战漫天飞，我迷惑了，于是结论大项目建小项目不建，这结论好似牵强，才疏学浅，万高手解答之，这是二问。

问三：

  主键为何那么痛苦？

我第一用的Oracle建表是序列号，被经理痛批了，说100，最多给你60分还是加了安慰分,后来经理仔细说了情况，原来我们做的系统跟其他系统做了关联，特别是跟客户端Delphi，人家没有序列号，还有迁移你怎么办，于是全不改成了guid，看着这么一串，麻烦来了，怎么测试啊，毫无规律，最后看经理们设计的是，全系统用了一张全局主键维护表，感觉设计的很合理，还能做到所用用户功能（把用户主键生成表锁住，导致用户锁住），于是乎，从此以后，我爱上了这么模式，但也问了度娘，有这么几种方式

1.自动增长型字段：

      以前最爱，啥都数据库自己完成，但是不适合迁移

2手动增长型字段

      现在最爱，有规律，适合迁移，但是并发是个问题，每次都要从表里读取

3 guid

      最恨这种方式，感觉设计者不负责，老长的字段，害死了索引，不易测试，看不出鬼名堂

4使用“COMB（Combine）”类型

   没用过，看来思想后，很牛，以后可能走这种路线了

这几个问题纠结了我多年，有过经验是如何解决的，希望三问三答额。