<刁鑽專業-程式設計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，是「程式設計者的錯」, 而不是「使用者的錯」。
程式設計者的責任不只是「能跑」，也要能「能防止誤跑」。
程式設計就像造車，不能把危險交給使用者自己避免。
---
後記:
我承認我也是半吊子.
現在知識爆炸的世界, 誰不是半吊子?
選自 <<刁鑽>> 沈源有.
