設計開發

Gemini 回答 好的，作為一個資深的系統架構師與 AP 性能調校專家，我會為您提供一份在這次壓力測試中，從頭到尾、由外到內需要關注的參數設定與調校檢查清單。 我們的目標非常明確：在 50 個併發用戶（Concurrent Users）持續加壓一小時的條件下，確保 95% 的請求（95th Percentile）回應時間在 3 秒以內。 這是一個系統性的工程，我們需要從壓力來源、作業系統、應用伺服器、一直到資料庫，逐層分析與調校。 核心調校哲學 建立基準 (Establish Baseline): 在進行任何調校之前，先用預設設定跑一次縮短版的壓力測試（例如 10-15 分鐘）。這個數據是你的黃金標準，所有的後續調校都必須跟這個基準線做比較，才能判斷是改善還是惡化。 一次只改一個參數 (Change One Thing at a Time): 這是最重要的原則。如果你一次改了三個參數，效能變好了，你不會知道是哪個參數起了作用。反之，如果效能變差，你也不知道是誰的錯。 監控是你的眼睛 (Monitoring is Key): 如果沒有監控，調校就如同矇著眼睛開車。你必須能夠即時看到 CPU、記憶體、網路、I/O、GC、執行緒等關鍵指標的變化。 第一層：壓力來源 (JMeter) 確保壓力測試工具本身不是瓶頸。 參數/項目 建議與說明 啟動模式 絕對要使用命令列模式 (CLI Mode) 進行正式壓測，不要使用 GUI 模式。GUI 模式會消耗大量客戶端資源，影響測試準確性。指令範例：jmeter -n -t your_test_plan.jmx -l results.jtl JVM Heap Size 修改 jmeter.bat 或 jmeter.sh，調整 JMeter 的 JVM 堆疊大小。如果請求或回應的資料量大，預設的 1G 可能不夠。建議至少設為 HEAP="-Xms2g -Xmx2g" 或更高，避免 JMeter 本身 OutOfMemory。 監聽器 (Listeners) 在正式壓測時，禁用或刪除所有 GUI 上的監聽器，如 “View Results Tree”、“Summary Report” 等。它們非常消耗資源。測試結束後，再用 results.jtl 檔來產生報告。 思考時間 (Think Time) 在請求之間加入合理的思考時間 (e.g., Uniform Random Timer)，模擬真實用戶行為。完全沒有思考時間的壓測會對伺服器造成不切實際的瞬間衝擊，可能無法反映真實場景的效能瓶頸。 分散式壓測 如果單台 JMeter 機器無法產生足夠的壓力（CPU/網路滿載），應考慮使用主從式 (Master-Slave) 的分散式架構來發動壓測。 第二層：作業系統 (AIX) AIX 有其獨特的監控與調校工具，是穩定運行的基礎。 ...

安全程式碼指引 目錄 文件目的 通用安全開發原則 2.1 最小權限原則 2.2 輸入驗證 2.3 錯誤處理 2.4 加密使用原則 2.5 安全標頭設定 2.6 Session 與 Token 管理 程式語言安全指引 3.1 Java / Spring Boot 3.2 Python 3.3 JavaScript / TypeScript / Vue3 3.4 資料庫安全 OWASP Top 10 對應對策 4.1 A01:2021 – Broken Access Control (存取控制失效) 4.2 A02:2021 – Cryptographic Failures (加密失效) 4.3 A03:2021 – Injection (注入攻擊) 4.4 A04:2021 – Insecure Design (不安全設計) 4.5 A05:2021 – Security Misconfiguration (安全設定錯誤) 4.6 A06:2021 – Vulnerable Components (易受攻擊元件) 4.7 A07:2021 – Identification and Authentication Failures (識別與驗證失效) 4.8 A08:2021 – Software and Data Integrity Failures (軟體與資料完整性失效) 4.9 A09:2021 – Security Logging & Monitoring Failures (安全日誌與監控失效) 4.10 A10:2021 – Server-Side Request Forgery (SSRF) API 安全設計 5.1 RESTful API 安全 5.2 GraphQL 安全 5.3 API 版本控制與向後相容 5.4 API 速率限制與節流 容器化與雲端安全 6.1 Docker 安全 6.2 Kubernetes 安全 6.3 雲端服務安全 CI/CD 安全 7.1 代碼儲存庫安全 7.2 建構流程安全 7.3 部署安全 7.4 供應鏈安全 安全測試與驗證 8.1 靜態應用程式安全測試 (SAST) 8.2 動態應用程式安全測試 (DAST) 8.3 互動式應用程式安全測試 (IAST) 8.4 滲透測試 資料保護與隱私 9.1 個人資料保護 9.2 資料分類與標記 9.3 資料遮罩與匿名化 9.4 資料備份與復原 事件回應與復原 10.1 安全事件識別 10.2 事件回應流程 10.3 取證與證據保全 10.4 災難復原計畫 日常開發檢查清單 (Checklist) 11.1 每日開發檢查項目 11.2 Pull Request 檢查項目 11.3 部署前檢查項目 常見錯誤與反例 12.1 密碼處理錯誤 12.2 SQL 查詢錯誤 12.3 檔案上傳錯誤 12.4 前端 XSS 錯誤 12.5 權限控制錯誤 12.6 API 設計錯誤 12.7 配置錯誤 合規性與法規要求 13.1 GDPR 合規 13.2 個資法合規 13.3 PCI DSS 合規 13.4 SOX 合規 延伸資源 14.1 官方安全指引 14.2 程式語言特定資源 14.3 安全工具 14.4 學習資源 14.5 公司內部資源 1. 文件目的 安全程式碼的撰寫是每位開發者的基本職責。良好的安全設計不僅能保護公司與用戶資料，避免資安事件造成商譽損失與法律責任，也有助於符合法規（如 GDPR、個資法）及客戶合約要求。安全程式碼能降低維運成本、減少漏洞修補時間，讓業務更穩健發展。 ...

後端開發指引 目錄 開發原則 專案結構與命名規範 API 設計規範 資料庫存取與 ORM 規範 安全性規範 效能與擴展性指引 測試與品質保證 部署與維運指引 日誌管理與監控 資料驗證與清理 國際化與本地化 文件生成與 API 規範 第三方整合規範 程式碼審查與品質控制 依賴與配置管理 備份與災難恢復 1. 開發原則 1.1 架構模式 Clean Architecture 實作原則 依賴反轉原則：內層不依賴外層，外層依賴內層 單一職責原則：每個類別/模組只負責一個職責 開放封閉原則：對擴展開放，對修改封閉 介面隔離原則：使用者不應依賴不需要的介面 架構分層結構： ┌─────────────────────────────────────┐ │ Presentation Layer │ ← Controllers, DTOs ├─────────────────────────────────────┤ │ Application Layer │ ← Use Cases, Services ├─────────────────────────────────────┤ │ Domain Layer │ ← Entities, Repositories ├─────────────────────────────────────┤ │ Infrastructure Layer │ ← Database, External APIs └─────────────────────────────────────┘ 分層設計規範 Presentation Layer（表現層） ...

系統架構設計指引 目錄 1. 架構設計原則 1.1 設計核心原則 1.2 技術選型原則 1.3 架構品質屬性 2. 系統整體架構圖 2.1 微服務拆分策略 2.2 API Gateway 設計 2.3 服務間通訊 2.4 服務網格架構 3. 前後端分離與微前端設計 3.1 微前端架構 3.2 前端技術棧 3.3 響應式設計 (RWD) 3.4 多語系支援 4. 後端分層架構 (Clean Architecture) 4.1 Clean Architecture 層級設計 4.2 目錄結構設計 4.3 依賴注入與配置 4.4 API 設計規範 5. 資料庫設計原則 5.1 多資料庫支援策略 5.2 資料分片與讀寫分離 5.3 資料庫設計範例 5.4 資料遷移策略 6. 效能優化方案 6.1 快取策略 6.2 快取配置範例 6.3 CDN 配置 6.4 非同步處理 6.5 負載平衡策略 6.6 效能基準測試 7. 高可用性與災難復原設計 ...

測試與品質保證指引 適用對象: 新進專案成員、開發人員、測試人員 文件目的: 快速理解專案的測試流程與品質保證規範 更新日期: 2025年8月27日 目錄 測試與品質保證的角色與責任 測試流程與各階段 測試計畫與測試案例設計 測試自動化與工具建議 缺陷管理流程 測試品質指標與衡量方式 測試與 CI/CD、版本控管、DevOps 的關聯 安全性測試與合規性驗證 效能測試與效能調校 測試資料管理與隱私保護 跨瀏覽器與跨平台測試 API 測試與微服務測試策略 常見錯誤與避免方式 新進成員的最佳實務與建議 測試與品質保證檢查清單 測試成本效益分析與 ROI 評估 團隊協作與溝通 1. 測試與品質保證的角色與責任 1.1 開發人員職責 主要責任 撰寫單元測試: 為每個新功能撰寫對應的單元測試 程式碼審查: 檢視同事的程式碼，確保品質標準 修復缺陷: 及時修復測試中發現的問題 文件維護: 更新技術文件和 API 說明 具體工作項目 ✅ 每個方法都有對應的單元測試 ✅ 程式碼覆蓋率達到 80% 以上 ✅ 遵循程式碼風格指引 ✅ 提交前執行本地測試 1.2 測試人員職責 主要責任 測試案例設計: 根據需求規格設計完整的測試案例 執行測試: 進行系統測試、整合測試、使用者驗收測試 缺陷追蹤: 記錄、追蹤並驗證缺陷修復 測試報告: 提供測試結果分析和品質評估 具體工作項目 ✅ 設計邊界值和異常情況測試 ✅ 執行回歸測試確保功能穩定 ✅ 驗證非功能性需求（效能、安全性） ✅ 提供測試執行報告 1.3 專案經理職責 主要責任 資源規劃: 安排測試時程和人力資源 風險管控: 識別並管理測試相關風險 品質監控: 監控專案整體品質指標 溝通協調: 協調開發、測試、業務單位間的合作 1.4 實務案例 案例一：銀行系統開發 情境：開發線上轉帳功能 - 開發人員：撰寫轉帳邏輯單元測試 - 測試人員：設計轉帳金額邊界值測試（0元、負數、超過限額） - 專案經理：確保測試覆蓋金管會法規要求 案例二：API 開發 情境：開發客戶資料查詢 API - 開發人員：測試 API 回應格式和錯誤處理 - 測試人員：驗證 API 安全性和效能 - 專案經理：確保符合個資保護規範 1.5 注意事項 ⚠️ 重要提醒 ...

程式寫作指引 目錄 前言 程式碼風格與命名規範 1.1 Java 命名規範 1.2 TypeScript/JavaScript 命名規範 1.3 程式碼格式化 1.4 實務案例與注意事項 註解與文件撰寫 2.1 JavaDoc 註解規範 2.2 TypeScript JSDoc 註解 2.3 程式碼內註解最佳實踐 2.4 API 文件撰寫 2.5 Vue 元件註解 2.6 實務案例與注意事項 錯誤處理與日誌紀錄 3.1 例外處理最佳實踐 3.2 日誌記錄最佳實踐 3.3 監控與告警設定 3.4 實務案例與注意事項 單元測試與TDD 4.1 JUnit 5 測試規範 4.2 TypeScript/Jest 測試規範 4.3 測試驅動開發（TDD）流程 4.4 測試覆蓋率與品質指標 4.5 實務案例與注意事項 安全性考量 5.1 輸入驗證與資料清理 5.2 認證和授權 5.3 XSS 攻擊防護 5.4 CSRF 攻擊防護 5.5 敏感資料處理 5.6 安全標頭配置 Spring Boot 常用功能實踐 6.1 JWT (JSON Web Token) 認證授權 6.2 Spring Data JPA 最佳實踐 6.3 Spring Batch 批次處理 6.4 Spring Cache 快取管理 6.5 Spring Boot 配置管理 資料庫設計與操作 7.1 資料庫設計原則 7.2 SQL 查詢優化 7.3 事務管理 7.4 資料遷移策略 7.5 資料庫監控與維護 效能優化 8.1 Java 應用程式效能優化 8.2 Spring Boot 效能調優 8.3 前端效能優化 8.4 快取策略優化 8.5 監控和指標 8.6 效能測試 8.7 效能優化檢查清單 容器化與DevOps 9.1 Docker 容器化實踐 9.2 CI/CD 流水線設計 9.3 Kubernetes 部署策略 9.4 基礎設施即代碼 9.5 監控與日誌聚合 微服務架構 10.1 微服務設計原則 10.2 服務間通信 10.3 分散式事務處理 10.4 服務發現與負載均衡 10.5 API Gateway 設計 版本控制 11.1 Git 工作流程規範 11.2 提交訊息規範 11.3 代碼審查流程 11.4 分支保護和自動化 11.5 版本標記和發布 11.6 協作最佳實踐 11.7 版本控制檢查清單 最佳實踐總結 12.1 開發生命週期最佳實踐 12.2 程式碼品質標準 12.3 測試策略總覽 12.4 效能監控最佳實踐 12.5 部署和運維最佳實踐 12.6 持續改進流程 12.7 團隊協作指南 12.8 總結與展望 前言 本指引旨在幫助開發團隊撰寫高品質、可維護且安全的程式碼。無論您是剛入行的新進開發人員，還是經驗豐富的資深工程師，都可以透過這份指引提升程式設計技能，並確保專案的長期成功。 ...

系統架構設計範本 Prompt 目標 指導 AI 進行完整的系統架構設計，產生技術架構文檔和設計決策說明。 角色設定 你是一位資深系統架構師，具備豐富的大型系統設計經驗，熟悉各種架構模式、設計原則和最佳實務。 任務描述 請協助我完成 {專案名稱} 的系統架構設計工作。 專案技術背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、微服務、分散式系統} 預期使用者規模: {填入使用者數量級，如：1000、10萬、100萬} 效能要求: {填入關鍵效能指標} 技術棧偏好: {填入偏好的技術棧，如：Java/Spring、.NET、Python/Django} 部署環境: {填入部署方式，如：雲端、地端、混合雲} 架構設計要求 請按照以下結構進行系統架構設計： 1. 系統概覽 系統邊界定義 主要組件識別 系統上下文圖 利害關係人視圖 2. 架構風格選擇 架構風格評估 設計原則定義 品質屬性分析 技術決策記錄 3. 邏輯架構設計 分層架構設計 組件劃分 介面定義 資料流設計 4. 物理架構設計 部署拓撲 基礎設施規劃 網路設計 安全架構 5. 技術選型 框架和函式庫選擇 資料庫技術選型 中介軟體選擇 工具和平台決策 6. 品質屬性設計 可用性設計 效能最佳化 安全性設計 可維護性考量 輸出格式 # {專案名稱} 系統架構設計文檔 ## 1. 系統概覽 ### 1.1 系統目標 **主要目標:** [系統主要目標描述] **次要目標:** [次要目標列表] **成功標準:** [可測量的成功指標] ### 1.2 系統邊界 **包含範圍:** - [功能模組1] - [功能模組2] - [功能模組3] **排除範圍:** - [不包含的功能1] - [不包含的功能2] ### 1.3 系統上下文圖 [使用者] –> [系統] –> [外部系統A] | v [外部系統B] ...

專案系統設計指引 文件資訊 文件名稱: 專案系統設計指引 文件版本: v1.1 建立日期: 2025-01-11 更新日期: 2025-08-29 適用範圍: 大型共用平台開發專案 目錄 概述 1.1 指引目的 1.2 適用範圍 1.3 設計原則 1.4 物件導向設計原則 1.4.1 SOLID 原則 1.4.2 物件導向設計方法論 系統架構設計 2.1 整體架構概覽 2.2 分層架構設計 2.2.1 前端層架構 2.2.2 後端層架構 (Clean Architecture) 2.2.3 領域驅動設計 (DDD) 架構模式 2.2.4 六角形架構 (Hexagonal Architecture) 2.3 微服務拆分原則 2.4 API Gateway 設計 2.5 CDN 與快取策略 模組與服務設計 3.1 服務設計原則 3.1.1 單一職責原則 3.1.2 服務自治性 3.1.3 物件導向設計模式應用 3.2 服務間通訊設計 3.3 資料流設計 資料庫設計 4.1 資料模型設計規範 4.2 多資料庫支援策略 4.2.1 資料庫抽象層 4.2.2 物件關聯映射 (ORM) 設計模式 4.2.3 分庫分表策略 4.3 讀寫分離設計 4.4 資料安全與加密 安全性設計 5.1 認證與授權機制 5.1.1 OAuth 2.0 + OpenID Connect 整合 5.1.2 JWT Token 設計 5.1.3 RBAC (Role-Based Access Control) 設計 5.1.4 安全設計模式 5.2 API 安全設計 5.3 OWASP Top 10 防護策略 整合與介接設計 ...

設計指引範本 Prompt 目標 指導 AI 進行軟體設計，建立符合設計原則、易於維護且可擴展的軟體設計。 角色設定 你是一位資深軟體設計師，具備豐富的軟體設計經驗，熟悉設計模式、SOLID 原則和軟體工程最佳實務。 任務描述 請協助我完成 {專案名稱} 的軟體設計工作。 專案設計背景 專案名稱: {填入專案名稱} 設計範圍: {填入設計範圍，如：核心模組、特定功能} 技術棧: {填入使用的技術棧} 設計約束: {填入設計限制和約束} 品質要求: {填入品質屬性要求} 設計要求 請按照以下結構進行設計： 1. 領域建模 核心領域識別 實體和值物件設計 聚合設計 領域服務設計 2. 架構設計 分層架構設計 模組劃分 依賴關係設計 介面設計 3. 詳細設計 類別設計 方法設計 資料結構設計 演算法設計 4. 設計模式應用 創建型模式 結構型模式 行為型模式 架構模式 5. 設計原則遵循 SOLID 原則 DRY 原則 KISS 原則 YAGNI 原則 輸出格式 # {專案名稱} 軟體設計文件 ## 1. 設計概述 ### 1.1 設計目標 **主要目標:** - {目標1} - {目標2} - {目標3} **品質屬性:** - **可維護性:** {可維護性要求} - **可擴展性:** {可擴展性要求} - **可重用性:** {可重用性要求} - **可測試性:** {可測試性要求} ### 1.2 設計約束 **技術約束:** - 程式語言: {程式語言} - 框架: {使用的框架} - 資料庫: {資料庫類型} - 部署環境: {部署環境} **業務約束:** - 效能要求: {效能指標} - 安全要求: {安全等級} - 相容性要求: {相容性需求} ## 2. 領域建模 ### 2.1 領域識別 #### 核心領域 (Core Domain) **領域名稱:** {核心業務領域} **複雜度:** 高 **業務價值:** 高 **描述:** {領域描述} **主要概念:** - {概念1}: {概念描述} - {概念2}: {概念描述} - {概念3}: {概念描述} #### 支援領域 (Supporting Domain) **領域名稱:** {支援領域} **複雜度:** 中 **業務價值:** 中 **描述:** {領域描述} #### 通用領域 (Generic Domain) **領域名稱:** {通用領域} **複雜度:** 低 **業務價值:** 低 **解決方案:** {現成解決方案或第三方服務} ### 2.2 實體設計 (Entity) #### 實體: {實體名稱} ```java /** * {實體描述} * 不變量: {業務規則和約束} */ public class {實體名稱} { // 唯一識別碼 private {ID類型} id; // 業務屬性 private {屬性類型} {屬性名稱}; // 建構子 public {實體名稱}({參數列表}) { // 驗證業務規則 validateBusinessRules(); this.{屬性} = {值}; } // 業務方法 public {返回類型} {業務方法名稱}({參數列表}) { // 業務邏輯實作 return {結果}; } // 不變量驗證 private void validateBusinessRules() { if ({條件}) { throw new {例外類型}("{錯誤訊息}"); } } // equals 和 hashCode 基於 ID @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {實體名稱})) return false; {實體名稱} other = ({實體名稱}) obj; return Objects.equals(id, other.id); } @Override public int hashCode() { return Objects.hash(id); } } 2.3 值物件設計 (Value Object) 值物件: {值物件名稱} /** * {值物件描述} * 特性: 不可變、值相等、自驗證 */ public final class {值物件名稱} { private final {屬性類型} {屬性名稱}; public {值物件名稱}({參數類型} {參數名稱}) { validate({參數名稱}); this.{屬性名稱} = {參數名稱}; } public {屬性類型} get{屬性名稱}() { return {屬性名稱}; } private void validate({參數類型} value) { if ({驗證條件}) { throw new IllegalArgumentException("{錯誤訊息}"); } } @Override public boolean equals(Object obj) { if (this == obj) return true; if (!(obj instanceof {值物件名稱})) return false; {值物件名稱} other = ({值物件名稱}) obj; return Objects.equals({屬性名稱}, other.{屬性名稱}); } @Override public int hashCode() { return Objects.hash({屬性名稱}); } @Override public String toString() { return "{值物件名稱}{" + "{屬性名稱}=" + {屬性名稱} + '}'; } } 2.4 聚合設計 (Aggregate) 聚合: {聚合名稱} /** * {聚合描述} * 聚合根: {聚合根實體} * 邊界: {聚合邊界說明} */ public class {聚合名稱} { // 聚合根 private {實體類型} {聚合根}; // 聚合內實體 private List<{實體類型}> {內部實體列表}; // 聚合建構 public {聚合名稱}({參數列表}) { this.{聚合根} = new {實體類型}({參數}); this.{內部實體列表} = new ArrayList<>(); } // 業務操作 public void {業務操作名稱}({參數列表}) { // 驗證聚合不變量 validateAggregateInvariants(); // 執行業務邏輯 {聚合根}.{業務方法}({參數}); // 發布領域事件 publishDomainEvent(new {事件類型}({事件資料})); } // 聚合不變量驗證 private void validateAggregateInvariants() { if ({不變量條件}) { throw new {例外類型}("{違反不變量訊息}"); } } // 取得聚合根 ID public {ID類型} getId() { return {聚合根}.getId(); } } 2.5 領域服務設計 領域服務: {服務名稱} /** * {服務描述} * 使用場景: {使用場景說明} */ @DomainService public class {服務名稱} { private final {依賴類型} {依賴名稱}; public {服務名稱}({依賴類型} {依賴名稱}) { this.{依賴名稱} = {依賴名稱}; } /** * {業務操作描述} * @param {參數} {參數描述} * @return {返回值描述} */ public {返回類型} {業務操作}({參數列表}) { // 前置條件檢查 validatePreconditions({參數}); // 業務邏輯執行 {返回類型} result = executeBusinessLogic({參數}); // 後置條件檢查 validatePostconditions(result); return result; } } 3. 架構設計 3.1 分層架構 四層架構設計 ┌─────────────────────────────────────┐ │ 展示層 (Presentation) │ ├─────────────────────────────────────┤ │ 應用層 (Application) │ ├─────────────────────────────────────┤ │ 領域層 (Domain) │ ├─────────────────────────────────────┤ │ 基礎設施層 (Infrastructure) │ └─────────────────────────────────────┘ 展示層 (Presentation Layer) 職責: ...

銀行大型共用平台 - 資料庫設計指引 文件資訊 文件名稱: 資料庫設計指引 版本: 2.0 建立日期: 2025-08-11 最後更新: 2025-08-29 作者: 資料庫架構師 適用範圍: 銀行大型共用平台專案 目錄 資料庫命名規範 欄位設計準則 主鍵、外鍵與唯一鍵設計規範 索引策略 資料分區與分表策略 資料庫正規化與反正規化設計 資料安全規範 資料庫版本控管與變更管理方法 性能調校原則與監控方法 資料庫備份與災難復原計劃 資料庫容量規劃 資料庫升級與遷移策略 資料庫日誌管理 資料庫測試與驗證 資料庫文件與註解 資料庫自動化與工具 資料庫監控與維護 資料庫性能測試 資料治理與品質管理 多租戶架構設計 雲端資料庫設計指引 資料庫DevOps實踐 法規遵循與合規要求 資料庫最佳實務總結 結論與未來發展 1. 資料庫命名規範 1.1 資料庫命名規範 原則: 使用英文、數字和底線，避免特殊字元 格式: {系統代碼}_{環境代碼}_DB 範例: BANK_PROD_DB、BANK_TEST_DB、BANK_DEV_DB 1.2 Schema 命名規範 原則: 依據功能模組或業務領域命名 格式: {模組代碼}_{功能代碼} 範例: CORE_ACCOUNT (核心帳戶) LOAN_MGMT (放款管理) RISK_CONTROL (風險控制) AUDIT_LOG (稽核日誌) 1.3 Table 命名規範 原則: 使用單數名詞，英文大寫，底線分隔 格式: {模組前綴}_{業務實體} 範例: ACC_CUSTOMER (客戶資料) LOAN_APPLICATION (放款申請) TXN_JOURNAL (交易日誌) 1.4 Column 命名規範 原則: 英文大寫，底線分隔，含義明確 通用欄位: ID - 主鍵 CREATED_DATE - 建立時間 CREATED_BY - 建立者 UPDATED_DATE - 更新時間 UPDATED_BY - 更新者 VERSION - 版本號 STATUS - 狀態 1.5 Index 命名規範 主鍵索引: PK_{表格名稱} 一般索引: IDX_{表格名稱}_{欄位名稱} 唯一索引: UK_{表格名稱}_{欄位名稱} 外鍵索引: FK_{表格名稱}_{參考表格名稱} 1.6 View 命名規範 格式: V_{模組前綴}_{功能描述} 範例: V_ACC_CUSTOMER_SUMMARY 1.7 Function 命名規範 格式: FN_{模組前綴}_{功能描述} 範例: FN_CORE_CALC_INTEREST 1.8 Trigger 命名規範 格式: TRG_{表格名稱}_{觸發時機}_{動作} 範例: TRG_ACC_CUSTOMER_BEFORE_UPDATE 2. 欄位設計準則 2.1 資料型別選擇原則 2.1.1 數值型別 用途 Oracle DB2 SQL Server PostgreSQL 整數 NUMBER(10) INTEGER INT INTEGER 長整數 NUMBER(19) BIGINT BIGINT BIGINT 金額 NUMBER(15,2) DECIMAL(15,2) DECIMAL(15,2) DECIMAL(15,2) 百分比 NUMBER(5,4) DECIMAL(5,4) DECIMAL(5,4) DECIMAL(5,4) 2.1.2 字串型別 用途 Oracle DB2 SQL Server PostgreSQL 固定長度 CHAR(n) CHAR(n) CHAR(n) CHAR(n) 變動長度 VARCHAR2(n) VARCHAR(n) VARCHAR(n) VARCHAR(n) 大文字 CLOB CLOB TEXT TEXT 2.1.3 日期時間型別 用途 Oracle DB2 SQL Server PostgreSQL 日期 DATE DATE DATE DATE 日期時間 TIMESTAMP TIMESTAMP DATETIME2 TIMESTAMP 時間戳記 TIMESTAMP(6) TIMESTAMP(6) DATETIME2(6) TIMESTAMP(6) 2.2 長度設計標準 客戶姓名: VARCHAR(100) 客戶ID: VARCHAR(20) 帳號: VARCHAR(20) 電話: VARCHAR(20) 地址: VARCHAR(200) 電子郵件: VARCHAR(100) 備註: VARCHAR(500) 2.3 NULL 值設計原則 不允許 NULL 的欄位: ...