※ 引述《a12345x (一只小浣熊)》之铭言：
: ※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.171.53.143
: ※ 文章网址: https://www.ptt.cc/bbs/Soft_Job/M.1549048423.A.89A.html
: 推 kurtsgm: 看了只能帮QQ了 真惨 外部被人凹 内部搞不定 02/02 03:20
: 推 iamshiao: 是不是你以为他厉害，其实他废到有找只是擅长打高空？ 02/02 03:24
: → iamshiao: 我很难相信协调性、耐性、规划能力跟效率都这么差的人 02/02 03:24
: → iamshiao: 程式能写的好到哪去 02/02 03:24
: 资工课程每科甚至硕士课程都能快90
: 跟同学1上课感想就是怎么每个题目你都会写
: 刚开始建立db时候是同学1觉得架构不够正规化
: 因此他提出他的架构叫我把改成这样
: 这次开放语言也是他教我怎么起手 之前小弟都没碰过
: db改版虽然使demo失败但是他将10字段y/n用2进位储存缩减成1个字段
: 使的后续开发变快
: 他说数据库上课有教过
: 这样可以将课堂融会贯通
: 小弟在这方面只能佩服
题外话, 如果你们做的是企业应用系统,
而且会有其他IT接手维运并扩展, 那这样搞其实不太适合.
实务上如果做到BCNF或以上,
则table会过于分散, 一方面是做报表组资料麻烦, 也可能因为SQL不熟拖慢效能
另一方面是测试功能时会造成自己的困扰, 测一个新功能要从头造资料到尾浪费时间.
最后, 有可能因为table关联性已不太明显, 造成某些功能又要开暂存表来收资料,
那就失去原本高度正规化的优点.
另外, 将状态字段使用各种代号缩减到只存在一个字段,
并不直觉且会造成接手人员维护上的困扰,
除非你们编辑详尽的代号对应文件.
那又产生一个问题, 未来要投入人力同时维护文件?
若没有其他衍生问题, 则单纯状态字段留在该主表并无不妥,
若是多状态字段, ex:表单进退关, 再另建表维护.
实务上内部系统开发人力只占整个系统成本的一小部分,
后面维护/扩增要投入的人力才是最大宗.
你同学看来实力非常坚强, 不过他的作法比较适合需要最佳化的产品RD.
: ※ 编辑: a12345x (1.171.53.143), 02/02/2019 03:35:00
: 推 anandydy529: 有一种人是很会用嘴写程式，让你遇到了 02/02 03:34
: 推 eeyellow: 你的"Team"从一开始就失控了，一定要先把规则都定好 02/02 03:42
: 推 eeyellow: 钱最重要先说，你亲戚先垫钱就不对了，建议先10~20头款 02/02 03:49
: → eeyellow: 每次Demo过了就再发放一定比例，最后拿到案子才给尾款 02/02 03:50
: → eeyellow: 而且没合约情况特殊，尾款比例一定要高。像你亲戚这么 02/02 03:51
: → eeyellow: 敢的乙方还真少见 02/02 03:51
: 推 eeyellow: 团队最怕自以为高手不合群的人 02/02 03:54
: → eeyellow: 你同学这样独断变更Schema，浪费其他人时间 02/02 03:56
: → eeyellow: 不管在哪个公司都会被黑到不行，还敢自称高手= = 02/02 03:57
: → eeyellow: 最后你补充的那些...是在反串同学是读死书吗？ 02/02 03:59
: → eeyellow: 功能没做出来，案子没拿到，就先做最佳化...嗯嗯... 02/02 04:00
: 推 alihue: 其实1说的也没错，课程顾好效益远大于这个没人带的案子。 02/02 06:51
: → alihue: 虽然是拿来打电动 02/02 06:51
: → testPtt: 协作一定要开spec 口头讲的大家到时候都说当初讲得不一样 02/02 07:06
: 推 vn509942: 类似这种外包临时约 本身风险就异常高 02/02 09:12
: 推 vn509942: 急件处理一定是找有信誉的老司机（烟 02/02 09:15
: 推 heru: 开会各种不到 工作不照进度自己乱砍DB 光这2点就该踢掉他了 02/02 09:37
: → heru: 有去开会都能产生认知落差了 何况全靠转述 02/02 09:40
: → x000032001: 一点软件工程概念都没有 版控也不用 谈需求订规格也不 02/02 09:41
: → x000032001: 到 再高分有什么用 02/02 09:41