※ 引述《ripple0129 (perry tsai)》之铭言：
: 在看过一些复杂的SQL指令后，
: 觉得这是个难以维护的东西。
难以维护这个词太笼统了，
你的难以维护是很多 join ? （其实对熟 sql 的来说这还非常简单）
或是很多巢状循环 ? （这也可以用 view 解决）
: 优点自然也是有的，
: 可以少写不少程式码。
: 而复杂的SQL指令不外乎Join了好几个Table，
: Where了好几种条件。
这样听起来很单纯很好维护。
: 想请教各位大大对于SQL的应用上，
: 单纯做CRUD然后给与对应的entity物件，
: 需要Join时就是Select Table出来，
: 之后再自行用程式码拼装。
疴... 你太轻忽 Database indexing 的能力了，
你自己拼装，多了数据库 io ，速度也不会比 indexed 后的资料用 sql 捞出来快。
indexing 早就在资讯界做了 N 年的研究，产生了 N 篇算法的论文，
啥 B-Tree, B+ Tree 等等
: 还是下达花式SQL指令降低程式码量好？
: 然后哪一种对数据库有较轻的负担？
当然是组 SQL 搂，
当你单一 Table 超过十几万笔、百万笔，每次执行单一个 query
就将资料加载到 application 做运算，最后只拿几十笔来用，你觉得这样会快吗?
: 反正规化的查询速度优势，
: 牺牲了正规后储存空间以及降低了资料一致性，
储存空间很便宜；
一致性要看该 case 重不重要。
最重要会做反正规化不外乎为了：
1. 增加速度
2. 降低数据库使用的资源
: 且对于程式码来说也降低维护性，
工程师都有程式或资料的洁癖，
有时候这些“降低维护性”的事可以避免你绕一大圈
增加一点维护性不算什么
: 在现今环境来说值得吗？
: 我个人的看法是维护性最高优先权，
一向都是看 case 为何。
像是你只是写个简单一两万内的小 case，
帮理发店纪录所有来过的客人的基本资料、消费纪录
你是要用最原生的语言（像 php）直接快速写完，
还是你还要抽接口、数据库反正规化、用 MVC Framework ?
: 在维护性低的情形下，
: 后面加入的程式码品质可能每况愈下。
: 程式码品质不断降低会造成数据库的损耗加重。
两者没有直接关系
: 最后可能得不偿失。
: 想了解我这样的观念是错误的吗？
一点小经验：
数据库资源有限（license还很贵），不像 application 层可以横向轻易地扩展，
数据库是很难做多台机器 load balancing 的，
就算有的话后面还是共用同一颗硬盘。
又或者是只能用 replication 做读写分离这种程度而已。
因此的确需要对于数据库资源使用有更多的考量
相反的 application 层大多可以轻易地横向复制，
有些运算也真的可以不必在数据库全部完成
然后数据库的世界很广，多去了解一下各种 index 适用于什么样的资料，如何精准地对
table 下 index；
资料正规化要如何设计，什么是 entity、什么是 relation 要先搞清楚
设计出来的 table schema 才会有弹性
另外整个架构还可以将一些全文检索改用 elastic search，
一些常用的资料放在 redis cache，都是常见的做法
举个实例：
以前我也遇过一张报表，是一张学期成绩单，
除了要先找出该位学生，还要找出他这学期哪几门课、教授是谁、学分数、分数、
有没有 pass、有没有抵免、有没有教育学程、班排名、系排名、有没有被 21
一个 sql 组出来大概超过百行吧（含一大堆子查询）
但是程式可以怎么设计呢?
每个学生修的课程、教授、学分数、分数、学期
先反正规化成一个 table(或view、indexed view)
一些单纯设定档的table放到redis cache，像是21规则、status code对应的文字等等
要用时再 application 层去组即可
然后每个学生的班排名、系排名也都反正规化到另外一张 table
最后只要简单的 sql 就能查到要的资料，我的设计逻辑再留个文件
维护也简单，只要确定底层的资料没错，在最上层只需要注重逻辑对不对就好
但是如果你要数据库完全走正规化的路，
每次都是即时查询，数据库资源吃很重，且很耗时喔
一点心得分享

以前在学校读书，都要求完全走正规化的路，我不知道这样会因此让loading变重

最初的问题在java web就像是batis和hibernate

当然不是整个table select回来拼装，而是每个table各自下要where的东西回来拼装，这样的话对DB的负担跟join比较的话哪个比较重呢？

请问太多join可以用什么方法解决? 谢谢

缩小资料集 走索引 进CACHE 降低IO 降低CPU资料面来看的话就是反正规化 增加重复资料降低串接

实务上开发方蛮难动到DB的，接案全包除外。

大公司不会轻易给外包商动DB, 更别提写SP跟view了有的是合约问题, 大公司之前的开发商有维护合约在, 后面接手的包商不能动这块.

有弹性的正规化感觉只能靠经验了给推

我觉得SQL要怎么写有很大部分是需求问题 被逼的时候就算你不想也得搞一堆复杂的判断....

推，原原po数据库没学好吧？当然把逻辑用sql做掉啊，用程式去筛是哪招……有join很正常，自己不懂不等于复杂、维护性低，是自己能力不到，结案。

什么都要trace到SQL不觉得维护性低吗？ORM framework根本没用，会写code的我觉得要了解SQL语法的不难吧，但真的会想包一层让它OO些

sql维护性低？?.......

老实说我个人完全不认同逻辑用SQL做掉，这个出bug直接进data，逻辑能往前送就往前送才能做到多重检查。除非必要根本不把逻辑做在SQL。

ORM 范围小的时候用起来很爽 范围大了怎么死都不晓得包一层起来有的人就连底下怎么跑的都不晓得了...

当你说花式SQL是减少程式码，就让人感觉你SQL不太熟...

的确是减少程式码，少了在程式码端拼装的过程

这是一个lambda的概念

让资料归资料，OO归OO吧..

看完回答后 真的建议去修数据库系统的课程

推这篇~

这篇正解啊...

学到了