Structured Query Language
SQL is a standardized declarative language for defining, querying, and manipulating relational data in database systems.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Missing indexing leads to slow queries
- Unsafe dynamic SQL generation can allow SQL injection
- Monolithic schemas hinder scaling and development
- Use prepared statements instead of dynamic SQL for security
- Regularly review and adapt indexing strategies
- Profile and refactor long-running queries
I/O & resources
- Relational schema data sources
- Business requirements for queries
- Access and authorization models
- Query results and reports
- Transactional state changes
- Metrics and monitoring data
Description
Structured Query Language (SQL) is a declarative language for defining, querying, and manipulating relational data. It standardizes operations such as SELECT, INSERT, UPDATE, DELETE, and supports transactions, joins and aggregation. SQL underpins relational database systems and shapes data modeling, integrity constraints and performance considerations.
✔Benefits
- Broad standardization and portability between systems
- Expressive query and aggregation capabilities
- Support for transactions and integrity constraints
✖Limitations
- Not ideal for very flexible schemaless data models
- Differences between dialects cause porting effort
- Complex queries can cause performance bottlenecks
Trade-offs
Metrics
- Average query latency
Average execution time of typical queries as an indicator of performance.
- Transactions per second
Number of completed transactions per time unit to measure throughput.
- Cache hit rate
Proportion of queries served from cache to evaluate efficiency.
Examples & implementations
Analytical query with JOIN and aggregation
Uses multiple tables, performs joins and GROUP BY to calculate revenue by product category.
Transactional update with rollback
Example of an ACID-compliant transaction that updates multiple tables and rolls back on error.
Schema migration with migration script
Illustration of a schema change including migration and backout scripts for safe rollout.
Implementation steps
Capture requirements and data model
Design and normalize schemas
Plan indexes and partitioning
Implement queries and analyze with EXPLAIN
⚠️ Technical debt & bottlenecks
Technical debt
- Legacy schemas lacking normalization
- Ad-hoc indexes without monitoring
- Outdated dialect-specific queries
Known bottlenecks
Misuse examples
- Dynamic SQL with unsafe parameters causing injection
- Missing indexes on large joins causing timeouts
- Using SQL for highly schemaless, document-based data
Typical traps
- Underestimating dialect differences during porting
- Incorrect use of transaction isolations
- Excessive indexing without query analysis
Required skills
Architectural drivers
Constraints
- • Dialect differences between implementations
- • Hardware and I/O limits of the database instance
- • Regulatory requirements for data storage