SQL達人的現場工作筆記 - Ch17 - 有關順序的冒險

知道視窗函數有多麼好用的人可能會有「這麼方便的工具怎麼這麼晚才問世，如果能早一點出現就好了」這樣的疑問。本章節將會介紹在視窗函數問世前的 SQL 發展脈絡。

姍姍來遲的主角

視窗函數於 1990 年代後半才納入 SQL 標準，且在 2000 年代才開始支援，而 MySQL 更是等到 2017 才開始支援。以下我們來看一下大致上的年代表及其發展。

視窗函數年代表

年份	發展概述
1999	Oracle 8i 與 DB2 UDB7.1 將視窗函數當成（局部的） OLAP 函數支援。 Oracle 與 IBM 共同提出讓視窗函數接受 ANSI 認證，並於 SQL:1999 納為選項。
2003	於 SQL:2003 標準化為 Full Level
2005	Microsoft 於 SQL Server 2005 開始支援
2009	PostgreSQL 於 8.4 版開始支援
2011	SQL:2011 標準化為框架
2017	MySQL 於 8.0.11(GA) 支援

所以，

為什麼視窗函數這麼晚才來呢？

作者認為原因有二，其一是因為在早期使用資料庫進行數據分析處理的風氣不高，所以視窗函數的彙整被認為不是那麼的必要。現在常用於大數據分析的 OLAP 技術其實也是於 1980 年代開始構思， 1990 年代後才有支援這項技術的 DBMS 問世。

而另外一個原因，作者認為是因為資料庫發展的初期，有些功能的實作與否伴隨著某種意識形態上的限制，底下則會開始稍微講述一下這段小故事。

列應該有順序嗎？

如前面的章節所提及的內容， RDB 與 SQL 的誕生，源於盡力排除「資料位置」這種低層次的概念，是一種提高資料抽象度的技術。所以「列順序」這種概念也因為這樣的設計本質而成為遭受攻擊的對象。

集合內的元素是無順序性的

所以在這段發展的期間其實就是伴隨著實務需求上與堅守資料庫設計最初的想法上的宗教戰爭（？）

由於當時 SQL 界的一些權威人士的發言，與他們堅守著排除「列順序」的這種看法，當時的工程師們難免會跟著認為「列沒有順序，也不該有順序」

而伴隨著時代的變遷，在 1990 年代後半，IBM 與 Oracle 一同向 ANSI 提出標準化的建議，最終在 SQL:1999 正是支援視窗函數