※ 引述《ripple0129 (perry tsai)》之铭言：
有感而发，分享一下我自己的想法。
: 在看过一些复杂的SQL指令后，
: 觉得这是个难以维护的东西。
: 优点自然也是有的，
: 可以少写不少程式码。
: 而复杂的SQL指令不外乎Join了好几个Table，
: Where了好几种条件。
: 想请教各位大大对于SQL的应用上，
: 单纯做CRUD然后给与对应的entity物件，
: 需要Join时就是Select Table出来，
: 之后再自行用程式码拼装。
: 还是下达花式SQL指令降低程式码量好？
看到复杂的SQL就觉得难以维护通常有几个原因：
1. 你SQL功力太差
2. 当初写这段SQL的人功力太差
3. 真的很复杂
如果看到复杂的SQL就觉得应该尽量搬到programming language来处理，其实是矫枉过正啦
之所以会觉得SQL复杂是因为
1. 写SQL的思维和写programming language不一样
2. SQL虽然已经有TRY-CATCH、循环，条件判断...等等功能，
但是毕竟它不像一般programming language一样成熟。
(programming language有framewrok可以用，有class、template、封装继承多型..等
可以你在写程式的时候尽量地code reuse)
很多对SQL不熟的人把一些业务逻辑写到stored procedure里面来，
SQL code自然变得又臭又长。
(曾经看过上千行的stored procedure，实在让人不想维护)
3. 很多公司倾向不找"只懂SQL，但是对SQL非常专精的expert"
: 然后哪一种对数据库有较轻的负担？
: 反正规化的查询速度优势，
: 牺牲了正规后储存空间以及降低了资料一致性，
: 且对于程式码来说也降低维护性，
: 在现今环境来说值得吗？
: 我个人的看法是维护性最高优先权，
: 在维护性低的情形下，
: 后面加入的程式码品质可能每况愈下。
: 程式码品质不断降低会造成数据库的损耗加重。
: 最后可能得不偿失。
: 想了解我这样的观念是错误的吗？
因为你是engineer，每天看程式，如果程式很脏你会很痛苦，
所以才会觉得维护性优先权最高。
如果你是PM，就不会觉得维护性的优先权最高。
优先权最高的是要能够卖钱，
要能够卖钱就要来看你提供的features是不是客户想要的，
再来是performance的问题，因为用起来很慢的话，客户会不爽，
最后才是维护性的问题。
如果你产品的卖不了钱，很快地整个project就会死了，所以也不需要维护了。
但是话说回来，这也是为什么程式会很脏的原因之一，
因为一些methodology都会希望你赶快把产品拿到市场上去做验证，
收集feedback之后，回来再做改进。
所以开发的时候总是把"在限定时间内，把features做出来"放在最优先。
至于code脏不脏那不是最重要的事情。反正之后再改就好。
其实程式脏还不是最可怕的，可怕的是架构脏。
程式脏还不难改。架构脏的话你想改也改不动，因为一改几乎就是整个重写。
更可怕的是有些架构就算你想重写也不行，因为已经和其他产品整合在一起，
你一改代表其他产品部门也要跟着改，其他产品部门你很难叫得动。
最可怕的如果你的产品是需要release到客户端的
万一旧的架构客户已经在用了，一旦新架构release出去，
客户要同时升级2个产品，不然会fail。比方说：
product A ver. 1 <