我讲讲我看法吧
※ 引述《trueQoo (幸运之神)》之铭言：
: 数据库这种情况很常见，就是不懂设计下的产物
: （学校没教是一种情况）
: 然而，你还不能说他们不懂设计，他们会反过来说是你不懂设计
: （闷了）
: 数据库界的奇怪现象
人天生自大,
这个真的是人性,
每个人都觉得自己懂,
说别人不懂,
大家在公司也一定看过那种完全没碰过程式的人讲得一嘴好程式,
要他来写,就缩起来说自己不是工程师不写,你写的时候,他意见又一大堆
会写程式就一定懂吗?
也不是,写程式很多人是乱写的...
懂不懂很主观,
我自己判断谁懂不懂的方法有两个,
一个是看他有没有在进修,有没有在不断学习,
另一个是看他会不会与非工作上的工程师交流,
像我们利用私人时间在网络上讨论聊技术,就是一种交流,
不管是第一个还是第二个,
关键都在于走出公司向外面的世界学习,
有错就改,有好的就学,
而且是要有"实作",不是只是听听聊聊而己,
若是只会躲在公司里闭门造车,
自己土法练钢搞出了个东西就觉得自己很利害,
这个就是不懂,
而且会爱说别人不懂,
遇到问题就会想找倒楣鬼擦屁股
: 1.拿掉 pk 与 fk，说这样效能会比较好（好在哪？）
: 2.多个字段合起来设定一个 pk
设组合键是可以的,
组合键缺点是会比较慢,
但主键的功能并不是只是增加效能,
同时也有防重复的功能,
所以设组合键来防重复是OK的,
例如记录一家店有卖那些东西,
这种表,把店号和商品号设为组合键是没问题的,
若组合键设到5个以上的话,
会影响到速度或维护的话,
再改成单一主键配合索引处理
: 3.一个人有多个电话，会设计成 tel1 tel2 tel3 多个字段
我会喜欢研究数据库,
有很大的原因是因为数据库是很讲究"策略"的,
比较没有固定的做法,
要考虑的因素很多,
很灵活的,
我早年是走UI的,
走UI觉得太杂太闷,有意见的人太多,就改走数据库了...
像你举的电话的问题,
设计成tel1,tel2也没什么不好呀.
如果需求上只是要一个主电话,一个备用电话,
真的设在一张表就好...
就算有人有5个电话,他也只要写2个就好,不用全写
但是,假设我们今天要建一个罪犯档案,
罪犯逃来逃去,搞不好会有10支电话,
而我们又必需要记录到罪犯所有的电话,
这时候就需要把电话另外建表了
: 4.为了正规化而设计数据库，而不是为了使用者需求，也不是为了效能
我以前唸书时教到正规化,
只知道正规化,
但后来考证照时,
讲师讲到反正规化,
我才知道反正规化,
我才知道正规化只是个选择,
正规化也有缺点,
反正规化也未必不好,
因为各有优缺,
所以要视情况设计,
数据库设计时,
要能想到一年后的状况,
甚至五年后的状况,
这就是数据库迷人的地方,
没有策略观念的人做不好数据库
: 5.用应用程式去做原本数据库该做的资料检查
: 让我想到，这种数据库品质想要做什么资料仓储，我也是觉得很不可思议
我是不太了解你讲的资料检查是什么,
比较严谨的话,
确实在数据库里要做检查,
但如果成员对数据库不熟,
那用他擅长的工具来做检查,
也是可以的,
最终还是要回到问题有没有解决上,
不应该是型式