Database
Principles and query writing rules I follow when working with databases.
Core Principles
1. Audit Trail (Required 5 Fields)
All tables must include these 5 required fields:
| |
2. Soft Delete (Physical Delete Forbidden)
Absolutely Forbidden: No DELETE queries
| |
3. JPA Entity Design
Base Entity with Audit Trail and Soft Delete
| |
| |
Spring Data JPA Repository
Basic Queries
| |
INSERT
| |
UPDATE
| |
Soft DELETE
| |
Using QueryDSL
Configuration
| |
Basic Queries
| |
JOIN Queries
| |
Pagination
| |
Aggregate Functions
| |
Subqueries
| |
EXISTS Queries
| |
Dynamic Queries
| |
Projection (Direct DTO Query)
| |
Transactions
| |
Bulk Operations
| |
Index Strategy
Recommended Indexes
| |
Solving N+1 Problem
| |
Concurrency Control
Optimistic Locking
Used in environments where conflicts rarely occur. Suitable when there are many reads and few updates.
| |
Use cases:
- Many reads and few updates
- Low conflict probability
- Reducing database lock overhead
Pessimistic Locking
Used in environments where conflicts occur frequently. Suitable for inventory management, reservation systems, etc.
| |
Use cases:
- Inventory management (stock deduction)
- Seat reservation systems
- Financial transactions
- Frequent conflicts
Deadlock prevention strategy:
| |
Performance Optimization
Batch Processing
Memory-efficient processing of large data volumes.
| |
application.yml batch configuration:
| |
Query Optimization
| |
Native Query precautions:
| |
Caching Strategy
| |
Enhanced Transaction Management
Isolation Level
| |
Isolation level characteristics:
| Isolation Level | Dirty Read | Non-Repeatable Read | Phantom Read | Performance | Use Case |
|---|---|---|---|---|---|
| READ_UNCOMMITTED | Occurs | Occurs | Occurs | Highest | Rarely used |
| READ_COMMITTED | Prevented | Occurs | Occurs | High | Most cases (default) |
| REPEATABLE_READ | Prevented | Prevented | Occurs | Medium | Transaction consistency needed |
| SERIALIZABLE | Prevented | Prevented | Prevented | Low | Critical operations (financial) |
Propagation Options
| |
Propagation options guide:
- REQUIRED (default): Use for most cases
- REQUIRES_NEW: Audit logs, event records that need independent storage
- SUPPORTS: Read-only operations not requiring transactions
- NOT_SUPPORTED: Run without transaction (performance optimization)
- MANDATORY: Must be called within transaction (validation)
- NEVER: Exception if called within transaction (validation)
Enhanced Index Strategy
Composite Index Order
| |
Index order principles:
- High cardinality columns first (email, unique ID, etc.)
- Frequently used columns in WHERE clause first
- Equality (=) comparison before range search columns
- deleted_at always last
Index Anti-patterns
| |
Index creation guide:
- Limit indexes to 5-7 per table
- Create only on columns frequently used in WHERE, JOIN, ORDER BY
- Cover multiple query patterns with composite indexes
- Periodically remove unused indexes
- Monitor index size (recommended within 20% of table size)
Security
Soft Delete Security
| |
Sensitive Data Encryption
| |
SQL Injection Prevention
| |
Checklist
When Writing Queries
- Does every WHERE clause include the
deletedAt IS NULLcondition? - Are you using Soft Delete instead of DELETE queries?
- Are you updating Audit Trail fields during INSERT/UPDATE?
- Are you using projections (DTOs) to query only required fields?
- Are you specifying explicit columns instead of SELECT *?
- Are you using parameter binding to prevent SQL Injection?
When Designing Tables
- Does the table include all 5 Audit Trail fields?
- Does the deleted_at column exist?
- Are appropriate indexes created?
- Is the composite index column order correct? (high cardinality first)
- Are Foreign Key constraints configured?
- Is encryption applied to sensitive data?
Performance Optimization
- Is there no N+1 problem? (Fetch Join or Batch Size configuration)
- Are you using projections to avoid querying unnecessary data?
- Did you apply pagination?
- Does the query utilize indexes?
- Are you using batch processing for large data volumes?
- Are you managing memory with EntityManager flush/clear pattern?
- Is caching applied to frequently accessed data?
Concurrency Control
- Is locking applied to data that can be concurrently modified?
- Did you choose between optimistic vs pessimistic locking appropriately?
- Is there retry logic for OptimisticLockException?
- Is timeout configured when using pessimistic locking?
- Are locks sorted to prevent deadlocks?
Transaction Management
- Is @Transactional annotation properly applied?
- Is the Isolation Level explicitly configured?
- Does the Propagation option match business requirements?
- Are you using REQUIRED vs REQUIRES_NEW correctly?
- Is readOnly = true set for read-only transactions?
Security
- Are deleted data prevented from being queried?
- Is sensitive data encrypted before storage?
- Is there protection against SQL Injection attacks?
- Are user permissions validated?
- Is personal information collected minimally?