在看过一些复杂的SQL指令后，
觉得这是个难以维护的东西。
优点自然也是有的，
可以少写不少程式码。
而复杂的SQL指令不外乎Join了好几个Table，
Where了好几种条件。
想请教各位大大对于SQL的应用上，
单纯做CRUD然后给与对应的entity物件，
需要Join时就是Select Table出来，
之后再自行用程式码拼装。
还是下达花式SQL指令降低程式码量好？
然后哪一种对数据库有较轻的负担？
反正规化的查询速度优势，
牺牲了正规后储存空间以及降低了资料一致性，
且对于程式码来说也降低维护性，
在现今环境来说值得吗？
我个人的看法是维护性最高优先权，
在维护性低的情形下，
后面加入的程式码品质可能每况愈下。
程式码品质不断降低会造成数据库的损耗加重。
最后可能得不偿失。
想了解我这样的观念是错误的吗？
作者:
pttworld (批踢踢世界)
2016-10-15 02:28:00第一问题要看使用的framework。第二问题是文件做好则没有一定。第三问题相关性小。扩充时能否维持前人的程式品质。
作者:
bobju (枯藤老树昏鸦)
2016-10-15 09:06:00理论上跟实务上经常要有所取舍。你说的问题的确有，怎么做则视个案而定。
作者: travelerX 2016-10-15 09:08:00
先where 筛选, 不join 大表 , 需要join大表时拆成两次查询，再用程式比对会快很多（上次看到一个1xx万笔资料table join 1xx万笔资料再where的要跑12秒）
作者:
yyc1217 (somo)
2016-10-15 10:37:00两种状况都遇过 看专案 没有一定答案
作者:
Masakiad (Masaki)
2016-10-15 10:40:00除非明显的可以看出差距不然开发当下以好维护为主所以通常都等出现瓶颈在抓比较符合现实状况，有的功能根本一辈子不会出现瓶颈，不用担心太早...
花式SQL主要目的不是减少程式码，是求效能会觉得不好维护那是你对 framework 比对 SQL 熟相反的对 SQL 比对 framework 熟的就觉得拆开抓到程式中并比较难维护SQL也能作到先筛选再join，够熟SQL能作到许多framework作不到的事
作者:
mathrew (Joey)
2016-10-16 21:04:00算成本