Let's compare two of the biggest ways to work with data on the IBM i platform: DDS and SQL.
You already know DDS stands for Data Description Specifications. It has been the traditional way to define physical files, logical files, display files and printer files for decades. SQL on the other hand is the modern, standards-based language that lets you create tables, views, indexes and run powerful data queries directly.
Both technologies live happily side by side on IBM i and many shops use a mix of them.
DDS (Data Description Specifications)
The traditional, fixed‑format way to define IBM i objects like PFs, LFs, DSPFs, and PRTFs.
SQL (Structured Query Language)
The modern, industry‑standard way to define, query, and manage relational data.
Both coexist on IBM i, and both are supported by IBM. But they shine in different situations.
When to Use SQL
SQL is the preferred choice for modern database design and anything that needs flexibility, performance, or integration with non‑IBM i tools.
SQL uses free-format, English-like statements. You write CREATE TABLE, CREATE VIEW, CREATE INDEX and so on. It follows the ANSI SQL standard so skills you learn here transfer to other databases. On IBM i you can run SQL statements from the command line, inside RPGLE programs, or through modern IDEs.
Use SQL when you need:
Modern database features Identity columns, constraints, triggers, views, indexes, foreign keys, long field names.
Better performance SQL Query Engine (SQE) is optimized for SQL‑defined objects.
Interoperability External tools, BI platforms, ETL pipelines, and web apps expect SQL schemas.
Easier maintenance DDL scripts are portable, version‑controlled, and readable.
Future‑proofing IBM invests heavily in SQL enhancements—not DDS.
Typical SQL Use Cases
- Creating new databases or tables
- Adding constraints (PK, FK, CHECK)
- Building modern APIs or web services
- Reporting and analytics
- High‑performance indexing
- Data warehousing or integration projects
When to Use DDS
DDS is a positional, column-oriented language. You write it in fixed columns with specific keywords in certain positions. It feels very native to the IBM i green screen world and it compiles straight into objects that the operating system understands perfectly.
DDS still matters - especially in legacy environments and UI definitions.
Use DDS when you need:
- Display files (DSPF) SQL cannot define green‑screen UIs.
- Printer files (PRTF) SQL has no equivalent for formatting printed output.
- Legacy compatibility Many existing applications rely on DDS-defined PFs and LFs.
- Simple logical views DDS LFs are still useful for record‑level access in RPG.
- Minimal change impact If a system has decades of DDS-based logic, SQL conversion may be risky.
Typical DDS Use Cases
- Maintaining existing PF/LF structures
- Creating or modifying green‑screen interfaces
- Building printer layouts
- Supporting older RPG programs that expect record-level access
DDS vs SQL: Quick Comparison
Feature / Need | DDS | SQL |
|---|---|---|
Define PF/LF |  Yes | Yes (better) |
Define DSPF/PRTF | Yes |  No |
Modern database features | Limited | Extensive |
Long field names | No | Yes |
Constraints & referential integrity | No | Yes |
Performance optimization | Older CQE | SQE optimized |
External tool compatibility | Poor | Excellent |
Legacy RPG compatibility | Strong | Strong |
Practical Rule of Thumb
If you’re building something new → Use SQL.
It’s modern, powerful, and future‑proof.
If you’re maintaining or extending legacy code → Use DDS where it already exists.
Don’t break what works unless you’re ready for a full modernization.