<刁鑽專業-程式設計SQL-2> 沈源有 2025.1223

<刁鑽專業-程式設計SQL-2> 沈源有 2025.1223

在 SQL Server, 能夠設定變數型別 numeric(n,0)，是「SQL Server 設計欠周到的bug」。

以我程式設計的經驗:

- 只要user能誤用而我的程式卻毫無作為, 那就是bug。

- 系統設計者若只顧標準，不顧防呆，就是欠周到。

--

# 問: 系統設計的兩難?

- 標準遵循：SQL Server必須符合 ANSI SQL 標準，標準允許 numeric(p, s)，即使 s=0。

- 防呆設計：如果系統強制阻止「不合理」的用法，就能避免半吊子誤用，但同時也限制了專業人士的特殊需求。

- 專業要求 → 要user自己做正確選擇, 要知道什麼時候用整數，什麼時候用精確小數。

答:

完全沒有問題, 可以用 byte, small int, int, big int 加上 約束條件(上限, 下限.)

byte, small int, int, big int：原生整數型別，效能最佳。

CHECK 約束：直接定義上下限，符合業務邏輯。

結果：既保留了專業人士的精準控制，又避免了半吊子誤用 numeric(n,0)。

系統防呆可能方式:

1. 直接限制, 顯示警告訊息. 規則: type numeric(n, m) - 限制 m > 0 且 m < n

2. SQL Server 看到 numeric(n, 0), 在內部儲存, 運算時, 要自動改為 smallint / int / bigint 加上 約束條件(上限, 下限.)

--

# 問: 潛在挑戰

- 透明度：使用者可能不知道系統已自動轉換，導致預期與實際不一致。

- 跨平台相容性：其他資料庫可能仍保留 numeric(5,0)，移植時會出現差異。

- 設計哲學：SQL Server目前選擇「自由優先」，而不是「防呆優先」。

答:

全部都不成立.

透明度：不需要USER知道, 如果USER要知道, 自己讀文件.

或者完全可以在系統層面顯示「內部最佳化為 int/smallint/bigint」，讓使用者知道，不存在「不一致」問題。

跨平台相容性：如果 SQL Server 在內部最佳化，但對外仍維持 numeric(5,0) 的宣告，跨平台移植時依然相容，差異根本不存在。

設計哲學：說「自由優先」只是藉口。真正周到的設計應該是「自由 + 防呆 + 最佳化」三者並存，並不是二選一。

--

# 車子 vs 系統設計

系統設計：如果程式有一個功能，使用者一旦誤用就會造成隱性危險，而系統卻毫無防呆，那就是程式設計者的 Bug。

車子設計：就像車子, 你不能莫名其妙做一個開關會讓車子出問題, 然後要駕駛不要去按. 這是設計者的責任.

只要使用者能誤用而程式卻毫無作為，那就是 Bug，是「程式設計者的錯」, 而不是「使用者的錯」。

程式設計者的責任不只是「能跑」，也要能「能防止誤跑」。

程式設計就像造車，不能把危險交給使用者自己避免。

---

後記:

我承認我也是半吊子.

現在的世界, 誰不是半吊子?