Hubbry Logo
SQLSQLMain
Open search
SQL
Community hub
SQL
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
SQL
SQL
SQL
View on Wikipedia
from Wikipedia

SQL (Structured Query Language)
ParadigmDeclarative
FamilyQuery language
Designed byDonald D. Chamberlin
Raymond F. Boyce
DeveloperISO/IEC JTC 1 (Joint Technical Committee 1) / SC 32 (Subcommittee 32) / WG 3 (Working Group 3)
First appeared1973; 52 years ago (1973)
Stable release
SQL:2023 / June 2023; 2 years ago (2023-06)
Typing disciplineStatic, strong
OSCross-platform
Websitewww.iso.org/standard/76583.html
Major implementations
Many
Dialects
Influenced by
Datalog
Influenced
CQL, LINQ, SPARQL, SOQL, PowerShell,[1] JPQL, jOOQ, N1QL, GQL
  • Structured Query Language at Wikibooks
SQL (file format)
Filename extension
.sql
Internet media type
application/sql[2][3]
Developed byISO/IEC
Initial release1986; 39 years ago (1986)
Type of formatDatabase
StandardISO/IEC 9075
Open format?Yes
Websitewww.iso.org/standard/76583.html

Structured Query Language (SQL) (pronounced /ˌɛsˌkjuˈɛl/ S-Q-L; or alternatively as /ˈsiːkwəl/ ⓘ "sequel") [4][5] is a domain-specific language used to manage data, especially in a relational database management system (RDBMS). It is particularly useful in handling structured data, i.e., data incorporating relations among entities and variables.

Introduced in the 1970s, SQL offered two main advantages over older read–write APIs such as ISAM or VSAM. Firstly, it introduced the concept of accessing many records with one single command. Secondly, it eliminates the need to specify how to reach a record, i.e., with or without an index.

Originally based upon relational algebra and tuple relational calculus, SQL consists of many types of statements,[6] which may be informally classed as sublanguages, commonly: data query language (DQL), data definition language (DDL), data control language (DCL), and data manipulation language (DML).[7]

The scope of SQL includes data query, data manipulation (insert, update, and delete), data definition (schema creation and modification), and data access control. Although SQL is essentially a declarative language (4GL), it also includes procedural elements.

SQL was one of the first commercial languages to use Edgar F. Codd's relational model. The model was described in his influential 1970 paper, "A Relational Model of Data for Large Shared Data Banks".[8] Despite not entirely adhering to the relational model as described by Codd, SQL became the most widely used database language.[9][10]

SQL became a standard of the American National Standards Institute (ANSI) in 1986 and of the International Organization for Standardization (ISO) in 1987.[11] Since then, the standard has been revised multiple times to include a larger set of features and incorporate common extensions. Despite the existence of standards, virtually no implementations in existence adhere to it fully, and most SQL code requires at least some changes before being ported to different database systems.

History

[edit]

SQL was initially developed at IBM by Donald D. Chamberlin and Raymond F. Boyce after learning about the relational model from Edgar F. Codd[12] in the early 1970s.[13] This version, initially called SEQUEL (Structured English Query Language), was designed to manipulate and retrieve data stored in IBM's original quasirelational database management system, System R, which a group at IBM San Jose Research Laboratory had developed during the 1970s.[13]

Chamberlin and Boyce's first attempt at a relational database language was SQUARE (Specifying Queries in A Relational Environment), but it was difficult to use due to subscript/superscript notation. After moving to the San Jose Research Laboratory in 1973, they began work on a sequel to SQUARE.[12] The original name SEQUEL, which is widely regarded as a pun on QUEL, the query language of Ingres,[14] was later changed to SQL (dropping the vowels) because "SEQUEL" was a trademark of the UK-based Hawker Siddeley Dynamics Engineering Limited company.[15] The label SQL later became the acronym for Structured Query Language.[16]

After testing SQL at customer test sites to determine the usefulness and practicality of the system, IBM began developing commercial products based on their System R prototype, including System/38, SQL/DS, and IBM Db2, which were commercially available in 1979, 1981, and 1983, respectively.[17] IBM's endorsement caused the industry to move to SQL from alternatives like QUEL.[18]

In the late 1970s, Relational Software, Inc. (now Oracle Corporation) saw the potential of the concepts described by Codd, Chamberlin, and Boyce, and developed their own SQL-based RDBMS with aspirations of selling it to the U.S. Navy, Central Intelligence Agency, and other U.S. government agencies. In June 1979, Relational Software introduced one of the first commercially available implementations of SQL, Oracle V2 (Version2) for VAX computers.

By 1986, ANSI and ISO standard groups officially adopted the standard "Database Language SQL" language definition. New versions of the standard were published in 1989, 1992, 1996, 1999, 2003, 2006, 2008, 2011,[12] 2016 and, most recently, 2023.[19]

Interoperability and standardization

[edit]
SQL language revisions

Overview

[edit]

SQL implementations are incompatible between vendors and do not necessarily completely follow standards. In particular, date and time syntax, string concatenation, NULLs, and comparison case sensitivity vary from vendor to vendor. PostgreSQL[20] and Mimer SQL[21] strive for standards compliance, though PostgreSQL does not adhere to the standard in all cases. For example, the folding of unquoted names to lower case in PostgreSQL is incompatible with the SQL standard,[22] which says that unquoted names should be folded to upper case.[23] Thus, according to the standard, Foo should be equivalent to FOO, not foo.

Popular implementations of SQL commonly omit support for basic features of Standard SQL, such as the DATE or TIME data types. The most obvious such examples, and incidentally the most popular commercial and proprietary SQL DBMSs, are Oracle (whose DATE behaves as DATETIME,[24][25] and lacks a TIME type)[26] and MS SQL Server (before the 2008 version). As a result, SQL code can rarely be ported between database systems without modifications.

Reasons for incompatibility

[edit]

Several reasons for the lack of portability between database systems include:

  • The complexity and size of the SQL standard means that most implementers do not support the entire standard.
  • The SQL standard does not specify the database behavior in some important areas (e.g., indices, file storage), leaving implementations to decide how to behave.
  • The SQL standard defers some decisions to individual implementations, such as how to name a results column that was not named explicitly.[27]: 207 
  • The SQL standard precisely specifies the syntax that a conforming database system must implement. However, the standard's specification of the semantics of language constructs is less well-defined, leading to ambiguity.
  • Many database vendors have large existing customer bases; where the newer version of the SQL standard conflicts with the prior behavior of the vendor's database, the vendor may be unwilling to break backward compatibility.
  • Little commercial incentive exists for vendors to make changing database suppliers easier (see vendor lock-in).
  • Users evaluating database software tend to place other factors such as performance higher in their priorities than standards conformance.

Standardization history

[edit]

SQL was adopted as a standard by the ANSI in 1986 as SQL-86[28] and the ISO in 1987.[11] It is maintained by ISO/IEC JTC 1, Information technology, Subcommittee SC 32, Data management and interchange.

Until 1996, the National Institute of Standards and Technology (NIST) data-management standards program certified SQL DBMS compliance with the SQL standard. Vendors now self-certify the compliance of their products.[29]

The original standard declared that the official pronunciation for "SQL" was an initialism: /ˌɛsˌkjuːˈɛl/ ("ess cue el").[9] Regardless, many English-speaking database professionals (including Donald Chamberlin himself[30]) use the acronym-like pronunciation of /ˈsiːkwəl/ ("sequel"),[31] mirroring the language's prerelease development name, "SEQUEL".[13][15][30]
The SQL standard has gone through a number of revisions:

Timeline of SQL language
Year Official standard Informal
name 		Comments
1986
1987 		ANSI X3.135:1986
ISO/IEC 9075:1987
FIPS PUB 127 		SQL-86
SQL-87 		First formalized by ANSI, adopted as FIPS PUB 127
1989 ANSI X3.135-1989
ISO/IEC 9075:1989
FIPS PUB 127-1 		SQL-89 Minor revision that added integrity constraints, adopted as FIPS PUB 127-1
1992 ANSI X3.135-1992
ISO/IEC 9075:1992
FIPS PUB 127-2 		SQL-92
SQL2 		Major revision (ISO 9075), Entry Level SQL-92, adopted as FIPS PUB 127-2
1999 ISO/IEC 9075:1999 SQL:1999
SQL3 		Added regular expression matching, recursive queries (e.g., transitive closure), triggers, support for procedural and control-of-flow statements, nonscalar types (arrays), and some object-oriented features (e.g., structured types), support for embedding SQL in Java (SQL/OLB) and vice versa (SQL/JRT)
2003 ISO/IEC 9075:2003 SQL:2003 Introduced XML-related features (SQL/XML), window functions, standardized sequences, and columns with autogenerated values (including identity columns)
2006 ISO/IEC 9075-14:2006 SQL:2006 Adds Part 14, defines ways that SQL can be used with XML. It defines ways of importing and storing XML data in an SQL database, manipulating it within the database, and publishing both XML and conventional SQL data in XML form. In addition, it lets applications integrate queries into their SQL code with XQuery, the XML Query Language published by the World Wide Web Consortium (W3C), to concurrently access ordinary SQL-data and XML documents.[32]
2008 ISO/IEC 9075:2008 SQL:2008 Legalizes ORDER BY outside cursor definitions. Adds INSTEAD OF triggers, TRUNCATE statement,[33] FETCH clause
2011 ISO/IEC 9075:2011 SQL:2011 Adds temporal data (PERIOD FOR)[34] (more information at Temporal database#History). Enhancements for window functions and FETCH clause.[35]
2016 ISO/IEC 9075:2016 SQL:2016 Adds row pattern matching, polymorphic table functions, operations on JSON data stored in character string fields
2019 ISO/IEC 9075-15:2019 SQL:2019 Adds Part 15, multidimensional arrays (MDarray type and operators)
2023 ISO/IEC 9075:2023 SQL:2023 Adds data type JSON (SQL/Foundation); Adds Part 16, Property Graph Queries (SQL/PGQ)

Current standard

[edit]

The standard is commonly denoted by the pattern: ISO/IEC 9075-n:yyyy Part n: title, or, as a shortcut, ISO/IEC 9075. Interested parties may purchase the standards documents from ISO,[36] IEC, or ANSI. Some old drafts are freely available.[37][38]

ISO/IEC 9075 is complemented by ISO/IEC 13249: SQL Multimedia and Application Packages and some Technical reports.

Syntax

[edit]
Main article: SQL syntax
A chart showing several of the SQL language elements comprising a single statement

The SQL language is subdivided into several language elements, including:

  • Clauses, which are constituent components of statements and queries. (In some cases, these are optional.)[39]
  • Expressions, which can produce either scalar values, or tables consisting of columns and rows of data
  • Predicates, which specify conditions that can be evaluated to SQL three-valued logic (3VL) (true/false/unknown) or Boolean truth values and are used to limit the effects of statements and queries, or to change program flow.
  • Queries, which retrieve the data based on specific criteria. This is an important element of SQL.
  • Statements, which may have a persistent effect on schemata and data, or may control transactions, program flow, connections, sessions, or diagnostics.
    • SQL statements also include the semicolon (";") statement terminator. Though not required on every platform, it is defined as a standard part of the SQL grammar.
  • Insignificant whitespace is generally ignored in SQL statements and queries, making it easier to format SQL code for readability.

Procedural extensions

[edit]

SQL is designed for a specific purpose: to query data contained in a relational database. SQL is a set-based, declarative programming language, not an imperative programming language like C or BASIC. However, extensions to Standard SQL add procedural programming language functionality, such as control-of-flow constructs.

In addition to the standard SQL/PSM extensions and proprietary SQL extensions, procedural and object-oriented programmability is available on many SQL platforms via DBMS integration with other languages. The SQL standard defines SQL/JRT extensions (SQL Routines and Types for the Java Programming Language) to support Java code in SQL databases. Microsoft SQL Server 2005 uses the SQLCLR (SQL Server Common Language Runtime) to host managed .NET assemblies in the database, while prior versions of SQL Server were restricted to unmanaged extended stored procedures primarily written in C. PostgreSQL lets users write functions in a wide variety of languages—including Perl, Python, Tcl, JavaScript (PL/V8) and C.[40]

Alternatives

[edit]

A distinction should be made between alternatives to SQL as a language, and alternatives to the relational model itself. Below are proposed relational alternatives to the SQL language. See navigational database and NoSQL for alternatives to the relational model.

Distributed SQL processing

[edit]

Distributed Relational Database Architecture (DRDA) was designed by a workgroup within IBM from 1988 to 1994. DRDA enables network-connected relational databases to cooperate to fulfill SQL requests.[42][43]

An interactive user or program can issue SQL statements to a local RDB and receive tables of data and status indicators in reply from remote RDBs. SQL statements can also be compiled and stored in remote RDBs as packages and then invoked by package name. This is important for the efficient operation of application programs that issue complex, high-frequency queries. It is especially important when the tables to be accessed are located in remote systems.

The messages, protocols, and structural components of DRDA are defined by the Distributed Data Management Architecture. Distributed SQL processing ala DRDA is distinctive from contemporary distributed SQL databases.

Criticisms

[edit]

Design

[edit]

SQL deviates in several ways from its theoretical foundation, the relational model and its tuple calculus. In that model, a table is a set of tuples, while in SQL, tables and query results are lists of rows; the same row may occur multiple times, and the order of rows can be employed in queries (e.g., in the LIMIT clause). Critics argue that SQL should be replaced with a language that returns strictly to the original foundation: for example, see The Third Manifesto by Hugh Darwen and C.J. Date (2006, ISBN 0-321-39942-0).

Orthogonality and completeness

[edit]

Early specifications did not support major features, such as primary keys. Result sets could not be named, and subqueries had not been defined. These were added in 1992.[12]

The lack of sum types has been described as a roadblock to full use of SQL's user-defined types. JSON support, for example, needed to be added by a new standard in 2016.[44]

Null

[edit]

The concept of Null is the subject of some debate. The Null marker indicates the absence of a value, and is distinct from a value of 0 for an integer column or an empty string for a text column. The concept of Nulls enforces the 3-valued-logic in SQL, which is a concrete implementation of the general 3-valued logic.[12]

Duplicates

[edit]

Another popular criticism is that it allows duplicate rows, making integration with languages such as Python, whose data types might make accurately representing the data difficult,[12] in terms of parsing and by the absence of modularity. This is usually avoided by declaring a primary key, or a unique constraint, with one or more columns that uniquely identify a row in the table.

Impedance mismatch

[edit]

In a sense similar to object–relational impedance mismatch, a mismatch occurs between the declarative SQL language and the procedural languages in which SQL is typically embedded.[citation needed]

SQL data types

[edit]

The SQL standard defines three kinds of data types (chapter 4.1.1 of SQL/Foundation):

  • predefined data types
  • constructed types
  • user-defined types.

Constructed types are one of ARRAY, MULTISET, REF (reference), or ROW. User-defined types are comparable to classes in object-oriented language with their own constructors, observers, mutators, methods, inheritance, overloading, overwriting, interfaces, and so on. Predefined data types are intrinsically supported by the implementation.

Predefined data types

[edit]
  • Character types
    • Character (CHAR)
    • Character varying (VARCHAR)
    • Character large object (CLOB)
  • National character types
    • National character (NCHAR)
    • National character varying (NCHAR VARYING)
    • National character large object (NCLOB)
  • Binary types
    • Binary (BINARY)
    • Binary varying (VARBINARY)
    • Binary large object (BLOB)
  • Numeric types
    • Exact numeric types (NUMERIC, DECIMAL, SMALLINT, INTEGER, BIGINT)
    • Approximate numeric types (FLOAT, REAL, DOUBLE PRECISION)
    • Decimal floating-point type (DECFLOAT)
  • Datetime types (DATE, TIME, TIMESTAMP)
  • Interval type (INTERVAL)
  • Boolean
  • XML (see SQL/XML)[45]
  • JSON

See also

[edit]

Notes

[edit]

References

[edit]

Sources

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

SQL

View on Grokipedia
from Grokipedia
Structured Query Language (SQL) is a domain-specific, language designed for managing and manipulating data in management systems (RDBMS), such as , , , , and SQL Server. It enables users to perform operations like querying, inserting, updating, and deleting data through standardized commands, facilitating efficient interaction with structured data stored in tables. Originally developed to implement Edgar F. Codd's , SQL has become the foundational language for database operations across industries, supporting tasks from simple data retrieval to complex analytics and . SQL's origins trace back to the early 1970s at , where researchers and created it as (Structured English QUEry Language) to query relational databases based on Codd's 1970 paper on the relational . Due to issues, it was renamed SQL in 1974 and first implemented in 1979 with 's System R prototype. Early adoption grew through relational databases like in 1979 and 's DB2 in 1983, establishing SQL as a critical tool for in and scientific applications. Standardization began in 1986 when the (ANSI) published SQL-86 (ANSI X3.135-1986), the first formal specification, which was quickly adopted internationally by the (ISO) as ISO/IEC 9075:1987. Subsequent revisions include SQL-89 (minor updates for integrity constraints), the influential (adding features like outer joins and ), SQL:1999 (introducing object-relational extensions), and more recent versions up to SQL:2023, which enhances support for , property graphs, and temporal data. These standards, developed by ANSI's INCITS and ISO/IEC JTC 1/SC 32 committees, ensure portability across RDBMS vendors while allowing proprietary extensions like Oracle's or Microsoft's T-SQL. Key features of SQL include its declarative nature, where users specify what data is needed rather than how to retrieve it, enabling query optimizers to handle efficiency; support for ACID-compliant transactions to maintain ; and for handling large datasets in enterprise environments. It integrates seamlessly with programming languages like Python, , and R for applications in , , and , while security mechanisms such as and encryption protect sensitive information. Despite the rise of alternatives, SQL remains dominant in modern systems due to its maturity and widespread ecosystem.

History and Development

Origins in Relational Model

The origins of SQL trace back to Edgar F. Codd's seminal 1970 paper, "A Relational Model of Data for Large Shared Data Banks," which introduced the as a framework for managing large-scale data storage and retrieval. In this work, Codd proposed representing data as relations—essentially tables with rows and columns—drawing from mathematical to ensure , where changes to physical storage do not affect logical access. Central to the model was , a procedural comprising operations like restriction (selection of rows based on conditions), projection (selection of specific columns while eliminating duplicates), and join (combining relations on common attributes). These operations provided a formal basis for manipulating relations without navigating physical pointers, addressing limitations in earlier hierarchical and network models. Building directly on Codd's , IBM initiated the System R project in at its San Jose Research Laboratory to prototype a full management system (DBMS). The project team, including and , developed (Structured English QUEry Language) as the query interface, aiming to translate into an English-like, declarative syntax accessible to non-programmers. Unlike procedural languages that required specifying how to retrieve data, focused on what data was needed, allowing users to express queries without concern for storage details or execution paths. This approach supported querying, programmed transactions, and dynamic environments with and recovery mechanisms. The name was later shortened to SQL in due to a trademark conflict with the UK-based aircraft company. Key early features of SEQUEL/SQL directly mirrored primitives, emphasizing simplicity and power for relational data manipulation. The SELECT statement implemented selection and projection, enabling users to filter rows by conditions and choose specific columns, as in retrieving employee names where exceeds a threshold. JOIN operations facilitated combining related tables, such as merging employee and department relations on a shared key, preserving Codd's emphasis on value-based associations over links. During System R's Phase Zero (1974–1975), an initial supported basic SELECT with subqueries, while full JOIN capabilities emerged in subsequent phases by , validating the language's viability for practical relational DBMS. These foundations established SQL as a user-friendly bridge between theoretical and real-world database applications.

Key Milestones and Implementations

The first commercial implementation of SQL arrived with Version 2 in 1979, marking the debut of a fully management system (RDBMS) available to businesses. Developed by Relational Software, Inc. (later renamed ), this release introduced SQL as a practical for structured , enabling efficient data retrieval and manipulation on minicomputers like the Digital Equipment Corporation's PDP-11. 's pioneering effort set the stage for SQL's transition from research prototype to enterprise tool, supporting early applications in inventory and financial systems. IBM followed with DB2 in 1983, a pivotal enterprise RDBMS that integrated SQL into mainframe environments, particularly on the operating system. Announced on June 7, 1983, and generally available in 1985, DB2 emphasized scalability and reliability for large-scale , becoming a cornerstone for banking and operations. Its adoption accelerated SQL's use in mission-critical workloads, with features like and driving compliance with emerging standards. Microsoft entered the SQL landscape in 1989 with SQL Server 1.0, initially a with Sybase and to port SQL functionality to and later Windows platforms. This release targeted mid-range servers, offering cost-effective alternatives to mainframe systems and facilitating SQL's penetration into personal computing and departmental applications. By providing tools for developers to build client-server architectures, SQL Server boosted SQL's accessibility for small to medium enterprises, evolving into a dominant force in Windows ecosystems. The open-source movement democratized SQL access in the mid-1990s, beginning with MySQL's founding in 1995 by David Axmark, Allan Larsson, and Michael "Monty" Widenius. The first stable release in May 1995 introduced a lightweight, multi-threaded RDBMS optimized for web applications, rapidly gaining traction among startups for its ease of deployment and zero-cost licensing. Similarly, emerged in 1996 as an evolution of the academic Postgres project, with version 6.0 renaming it to highlight SQL compliance while retaining advanced features like extensible types. These implementations lowered barriers to entry, enabling widespread experimentation and contributing to SQL's ubiquity in internet infrastructure. Standardization efforts culminated in ANSI's SQL-86 approval in 1986, the first formal specification (ANSI X3.135) that defined core for data definition and manipulation, adopted internationally by ISO in 1987. This standard spurred compliance, with early adopters like and aligning products to its entry-level requirements, reducing proprietary dialects and fostering interoperability. Over time, growing adherence—evident in certifications for SQL-89 revisions—encouraged broader integration, though full varied by . SQL played a central role in the late 1990s dot-com boom, powering the rapid scaling of web databases for and content management sites. As internet traffic surged, RDBMS like and handled dynamic queries for user sessions and transactions, supporting the era's "get big fast" strategies amid explosive venture funding. This period solidified SQL's position in high-volume environments, with adoption rates accelerating as companies built data-driven platforms. In the big data era, SQL adapted through integrations with distributed frameworks like Hadoop and , enabling queries over petabyte-scale datasets. Tools such as (introduced in 2008 but maturing in the ) provided SQL interfaces on Hadoop's HDFS, while Spark SQL (released in 2014) offered for faster analytics on . These extensions preserved SQL's declarative paradigm, bridging traditional RDBMS with systems and facilitating hybrid architectures in cloud environments.

Evolution to Modern Standards

The SQL standards evolved iteratively through revisions managed by ANSI and ISO, incorporating enhancements to address growing data complexity and analytical needs. The inaugural SQL-86 standard, published by ANSI in 1986 and adopted by ISO in 1987, established core syntax for data (DDL) and manipulation (DML), including SELECT, INSERT, UPDATE, DELETE, and basic elements like tables and views. SQL-89, a minor update in 1989, introduced integrity constraints such as primary keys, foreign keys, DEFAULT values, and CHECK conditions. , released in 1992, expanded query capabilities with explicit JOIN types (including outer joins), subqueries, set operations (UNION, INTERSECT, EXCEPT), and the CASE expression, while adding support for date/time data types and transaction isolation levels. Subsequent standards built on this foundation with advanced features. SQL:1999 introduced common table expressions (CTEs) enabling recursive queries, along with OLAP extensions like ROLLUP, CUBE, and GROUPING SETS for multidimensional analysis. SQL:2003 added window functions for row-based analytics, XML data type and querying support, and sequence generators. SQL:2008 incorporated temporal data handling, the MERGE statement for upsert operations, and the TRUNCATE TABLE command. SQL:2011 refined temporal features with period specifications and enhanced window framing options. SQL:2016 introduced row pattern recognition via the MATCH_RECOGNIZE clause for identifying sequences in result sets, initial JSON functions for document handling, and polymorphic table functions for dynamic schemas. The current SQL:2023 standard adds property graph queries (SQL/PGQ) as a new part for modeling and traversing graph data within relational tables, alongside a native JSON data type and expanded JSON operations. The advent of frameworks prompted SQL adaptations for distributed environments. , developed at and open-sourced in 2008, introduced HiveQL—a SQL dialect for querying petabyte-scale data stored in Hadoop Distributed File System (HDFS)—bridging traditional SQL with processing. , integrated into and first released in 2014, enabled SQL queries over structured data with in-memory computation, supporting complex analytics across clusters far beyond traditional RDBMS limits. Database vendors extended standards with proprietary innovations while pursuing compliance. attained full conformance in version 7.2, released in 2001, incorporating features like primary keys, quoted identifiers, and enhanced type casting. It later innovated with the JSONB type in version 9.4 (2014), a binary format for efficient storage and indexing, predating native standard support. Cloud-native services further modernized SQL by emphasizing serverless execution. Google BigQuery, announced in 2010 and generally available in 2011, pioneered a serverless using standard SQL to analyze terabytes of data without managing infrastructure. AWS Athena, launched in 2016, extended this model by allowing ad-hoc SQL queries on data in , leveraging Presto for federated access and pay-per-query pricing.

Standardization and Interoperability

Standardization Process

The standardization of SQL began with the (ANSI), which published the first formal SQL standard in 1986 as ANSI X3.135, aiming to establish a common language for relational database management systems amid growing proprietary implementations by vendors. This effort was adopted internationally by the (ISO) and the (IEC) in 1987 as ISO/IEC 9075, marking the start of ongoing global coordination. The primary responsibility for developing and revising SQL standards now lies with the ISO/IEC Joint Technical Committee 1 (JTC1) Subcommittee 32 (SC32) on and Interchange, specifically its Working Group 3 (WG3) on Database Languages. The standardization process is managed through collaborative drafting by WG3, which consists of representatives from national standards bodies, industry experts, and database vendors; this group convenes regular meetings—both in-person and virtual—to propose, debate, and refine technical specifications. Drafts undergo rigorous public review and balloting phases, where national member bodies submit comments and votes, often requiring multiple editing meetings to resolve issues before final approval by ISO. Major revisions typically occur in multi-year cycles of 3 to 5 years, though earlier intervals like the seven-year gap between and SQL:1999 reflect the complexity of achieving consensus on evolving features. For instance, the development of SQL:2023 involved over 30 WG3 meetings spanning several years, culminating in the submission of final text to the ISO Central Secretariat in early 2023. The core goals of this process are to promote portability and across database systems, thereby reducing by defining a baseline of consistent behavior that implementations can rely upon without dependencies. Standards distinguish between mandatory "Core SQL" features, which all conforming implementations must support, and optional "Enhanced SQL" features, allowing vendors flexibility for advanced capabilities while ensuring basic compatibility. In the , the push for arose directly from concerns over vendor-specific SQL dialects that locked users into particular systems, a problem addressed by ANSI's initial effort and amplified by the comprehensive revision, which achieved widespread adoption as vendors aligned their products with its entry-level requirements to demonstrate compliance. In recent cycles, the process has incorporated deliberations on modern data management needs, such as enhanced support for data handling and property graph queries, reflecting WG3's adaptation to contemporary applications like processing. These updates maintain the standard's relevance by balancing with incremental innovations, ensuring SQL remains a foundational technology for database .

Current SQL Standard (SQL:2023)

The SQL:2023 standard, officially known as ISO/IEC 9075:2023, was published by the (ISO) and the (IEC) in June 2023. This ninth edition of the SQL standard builds upon previous versions by introducing enhancements to support modern data models and querying paradigms. The standard is structured into 11 active parts, each addressing specific aspects of the language. For instance, Part 1 defines the framework, including grammar and processing rules; Part 2 covers the foundation, encompassing core data manipulation and features; Part 9 addresses management of external data; and Part 11 provides information and definition schemas. A notable addition is Part 16, dedicated to property graph queries. Key new features in SQL:2023 emphasize integration with contemporary data structures. The introduction of property graph queries in Part 16 allows users to model and traverse tabular data as property graphs using the clause, enabling efficient graph-based operations like path finding and without requiring a separate . Additionally, Part 2 enhances support with a native data type (feature T801), simplified path accessors, and item methods for constructing and manipulating values, including functions for dates and times that align with formatting conventions. The MERGE statement receives further refinements under optional feature F313, supporting more flexible conditional inserts, updates, and deletes in scenarios involving complex . These additions aim to bridge relational and non-relational paradigms while maintaining . Adoption of SQL:2023 remains partial across major database systems, as many features are optional and full compliance is uncommon due to implementation choices and performance considerations. 18, released in November 2025, builds on 16's (September 2023) initial enhancements, such as improved JSON functions and greatest/least aggregates, incorporating additional core aspects of the standard. 23ai (updated as of October 2025), succeeding the 23c preview from 2023, supports a broader range, including the new property graph queries via SQL/PGQ and advanced capabilities, positioning it as one of the more comprehensive implementations. However, no vendor achieves complete adherence to all optional features, leading to variations in supported syntax and behavior. Work on the next revision of the SQL standard is underway within ISO/IEC JTC1/SC32, expected in 3-5 years.

Compatibility Challenges Across Implementations

Despite efforts toward standardization, SQL implementations by major database vendors introduce compatibility challenges through proprietary extensions, selective adoption of optional features, and maintenance of legacy behaviors. Vendor extensions, such as Oracle's for and MySQL's distinct stored routine syntax, enhance functionality but diverge from the core SQL standard, complicating cross-database portability. Optional features in the SQL standard, like advanced window functions, are implemented inconsistently— for instance, some systems require specific syntax variations—while legacy support preserves older, non-standard behaviors to avoid breaking existing applications. Specific incompatibilities arise in common operations, including date handling, where systems differ in default formats and conversion rules. SQL Server relies on vendor-specific datetime types with implicit conversions that may lose precision when ported to systems like PostgreSQL, which adheres more closely to ISO 8601 standards for dates. Pagination syntax varies notably, with Microsoft SQL Server using the TOP clause (e.g., SELECT TOP 10 * FROM table) while MySQL and PostgreSQL employ LIMIT (e.g., SELECT * FROM table LIMIT 10), requiring query rewrites for interoperability. Regular expression support also differs: Oracle uses REGEXP_LIKE with POSIX-like patterns, SQL Server 2025 introduced REGEXP functions with its own dialect, and MySQL applies REGEXP with simpler Perl-compatible extensions, leading to pattern mismatches across platforms. To mitigate these issues, tools like SQLAlchemy provide an that generates dialect-specific SQL from neutral Python code, supporting over 20 databases since its initial release in 2005. Database migration services, such as Azure Database Migration Service and Cloud's Database Migration Service, automate schema and query translations during transitions, handling dialect differences through built-in converters. A representative case study involves porting queries from , an with non-standard SQL extensions like flexible typing, to , an enterprise system enforcing stricter type rules and lacking SQLite's PRAGMA statements. Developers must rewrite SQLite-specific date functions (e.g., strftime) to DB2's TIMESTAMP_FORMAT and adjust for DB2's absence of LIMIT, using FETCH FIRST instead, often requiring iterative testing to resolve syntax errors and discrepancies. Recent trends show increasing convergence through providers, where services like SQL for enable an ANSI SQL mode via the (e.g., setting ANSI_QUOTES), reducing reliance on vendor-specific quirks and promoting standard-compliant queries across hybrid environments.

Core Syntax and Components

Declarative Query Structure

SQL employs a declarative , allowing users to specify the desired output —what to retrieve—without prescribing the method of computation, leaving execution optimization to the database management system (DBMS). This non-procedural approach contrasts with imperative languages by focusing on set-oriented operations rather than row-by-row iteration, enabling concise expressions of complex queries. As introduced in the original , this facilitates interaction by non-specialists through simple block-structured English keywords. The foundational query in SQL is the SELECT statement, which follows the basic syntax: SELECT [DISTINCT] column_list FROM table_list [WHERE condition] [ORDER BY sort_expression] [GROUP BY grouping_expression]. This structure begins with selecting columns or expressions to include in the result (projection), identifies the source tables (relation), applies filtering conditions (restriction), and optionally sorts or groups the output. For instance, to retrieve names of employees earning more than $50,000 from an employees table, one might write:

SELECT name FROM employees WHERE salary > 50000 ORDER BY name;

SELECT name FROM employees WHERE salary > 50000 ORDER BY name;

This query assumes familiarity with relational concepts such as tables (relations) and rows (tuples). SQL's declarative clauses map directly to operations: the SELECT clause corresponds to the projection operator (π), which eliminates unwanted columns; the FROM clause implies a (×) across tables, often combined with joins; and the WHERE clause implements the selection operator (σ), restricting rows based on predicates. These mappings, rooted in the , ensure that queries describe logical relations without procedural steps. The non-procedural design yields benefits including enhanced readability, as queries resemble natural language and are easy to maintain, and improved portability, allowing applications to transfer across compatible DBMS implementations with minimal syntax changes. These advantages stem from the standardized, set-based formulation that prioritizes clarity over algorithmic detail.

Data Definition Language (DDL)

Data Definition Language (DDL) encompasses the subset of SQL commands responsible for defining, modifying, and deleting database schemas and structures, enabling the creation of foundational elements like tables and their associated components. These commands are integral to the ANSI/ISO SQL standard (ISO/IEC 9075), with core DDL features originating from SQL-86 and remaining largely consistent through subsequent revisions, including SQL:2023. DDL's emphasis on schema management ensures that database objects adhere to relational principles, such as integrity constraints, without directly manipulating data content. Due to its high level of standardization, DDL statements exhibit strong portability across major RDBMS vendors like Oracle, PostgreSQL, and SQL Server, minimizing syntax variations for basic operations. The CREATE TABLE statement is the cornerstone of DDL, allowing users to define a new table by specifying column names, data types, and optional constraints to enforce . For instance, to create a "Customers" table with an ID as the , a variable-length for the name, and an field with a NOT NULL constraint, the following syntax can be used:

sql

CREATE TABLE Customers ( ID INT PRIMARY KEY, Name VARCHAR(100), Email VARCHAR(255) NOT NULL );

CREATE TABLE Customers ( ID INT PRIMARY KEY, Name VARCHAR(100), Email VARCHAR(255) NOT NULL );

This command establishes the table schema in compliance with SQL:86 standards, where ensures uniqueness and non-nullability for the ID column, while NOT NULL prevents empty values in the Email column. Constraints like UNIQUE (to prevent duplicate values in non-key columns), CHECK (to validate data against a condition, e.g., ensuring age > 0), and (to link tables via ) are also defined during table creation to maintain relational consistency. ALTER TABLE enables modifications to an existing table's structure, such as adding, dropping, or altering columns, or adjusting constraints, without affecting the underlying data. A common operation is adding a new column, as in:

sql

ALTER TABLE Customers ADD Phone [VARCHAR](/page/Varchar)(20);

ALTER TABLE Customers ADD Phone [VARCHAR](/page/Varchar)(20);

This extends the dynamically, supporting operations like dropping a column (ALTER TABLE Customers DROP COLUMN Phone;) or adding a constraint to reference another table. Such alterations align with ISO/IEC 9075-2 (Foundation) requirements for schema evolution, though complex changes may require temporary tables in some implementations to preserve data. Conversely, the DROP TABLE command removes an entire table and its data irreversibly, as shown by:

sql

DROP TABLE Customers;

DROP TABLE Customers;

This operation, standardized since SQL-86, cascades to dependent objects if specified (e.g., DROP TABLE Customers CASCADE;), ensuring clean schema cleanup. Beyond tables, DDL includes commands for schema elements that enhance structure and performance. The CREATE INDEX statement builds an index on one or more columns to accelerate query retrieval, particularly for frequently searched fields; for example:

sql

CREATE INDEX idx_email ON Customers(Email);

CREATE INDEX idx_email ON Customers(Email);

Although not part of the core SQL standard, CREATE INDEX is widely supported across vendors for optional performance optimization, with as a common underlying structure. Similarly, CREATE VIEW defines a virtual table derived from a query, abstracting complex joins or filters without storing data physically:

sql

CREATE VIEW ActiveCustomers AS SELECT ID, Name FROM Customers WHERE Status = 'Active';

CREATE VIEW ActiveCustomers AS SELECT ID, Name FROM Customers WHERE Status = 'Active';

Views, standardized since SQL-86, promote data abstraction and security by limiting access to subsets of tables, and they are highly portable due to their reliance on standard SELECT syntax. Overall, DDL's standardized syntax facilitates schema portability, with core commands achieving near-universal compatibility, though advanced constraint may vary slightly by vendor implementation.

Data Manipulation Language (DML)

Data Manipulation Language (DML) encompasses the SQL statements responsible for modifying data within tables, including adding, altering, and removing records. These operations are essential for maintaining and updating database contents in a declarative manner, where the user specifies what changes to make without detailing how the executes them. Defined in the core of the SQL standard (ISO/IEC 9075-2: Foundation), DML statements form a foundational component of the language, enabling efficient data handling across compliant systems. The INSERT statement adds one or more new rows to a specified table, either by providing explicit values or by selecting from another query. Its basic follows the form INSERT INTO table_name (column_list) VALUES (value_list);, allowing insertion of single or multiple rows in a single operation. For instance, to add an employee record, one might use INSERT INTO Employees (id, name, salary) VALUES (101, 'Alice Johnson', 75000);. This statement conforms to the SQL standard, with extensions like RETURNING for retrieving inserted available in some implementations but not part of the core specification. The UPDATE statement modifies existing rows in a table by changing the values of specified columns, typically conditioned on a to target specific records. The syntax is UPDATE table_name SET column1 = expression1, column2 = expression2, ... WHERE condition;, which updates only the rows matching the condition and leaves others unchanged. An example is UPDATE Employees SET salary = salary * 1.1 WHERE department = 'IT';, which increases salaries for IT department employees by 10%. UPDATE adheres to the SQL standard, supporting subqueries in the for complex conditional logic, such as referencing data from other tables. The DELETE statement removes rows from a table based on a specified condition, emptying the table if no WHERE is provided. Its syntax is DELETE FROM table_name WHERE condition;, which deletes matching rows and preserves the table structure. For example, DELETE FROM Employees WHERE status = 'inactive'; removes all inactive employee records. This operation aligns with the SQL standard, and like UPDATE, it integrates subqueries in the WHERE to enable deletions based on dynamic criteria from other sources. The MERGE statement, also known as UPSERT, combines INSERT, UPDATE, and optionally DELETE operations into a single atomic statement, conditionally applying changes based on a join between source and target data. Introduced as an optional feature in SQL:2003 (ISO/IEC 9075-2), its syntax involves MERGE INTO target_table USING source_table ON join_condition WHEN MATCHED THEN UPDATE ... WHEN NOT MATCHED THEN INSERT ...;. A practical example is synchronizing customer data: MERGE INTO Customers c USING NewCustomers n ON c.id = n.id WHEN MATCHED THEN UPDATE SET c.email = n.email WHEN NOT MATCHED THEN INSERT (id, email) VALUES (n.id, n.email);. MERGE enhances efficiency for bulk tasks and supports subqueries in the source or conditions for refined matching. DML statements frequently integrate with SELECT through subqueries, allowing conditional modifications driven by queried data without needing separate transactions for reads and writes. For instance, an UPDATE might use a subquery like UPDATE Employees SET manager_id = (SELECT id FROM Managers WHERE location = 'HQ') WHERE department = 'Sales'; to assign a specific manager based on a dynamic selection. This capability, part of the SQL standard, promotes concise and powerful data manipulation while referencing schema elements defined elsewhere.

Procedural and Control Features

Procedural Extensions (PL/SQL, T-SQL)

Procedural extensions to SQL introduce constructs, enabling developers to write complex, reusable code within the database environment. These extensions augment SQL's declarative nature by incorporating control structures such as loops and conditionals, , and modular code organization through procedures and functions. Primarily vendor-specific, they facilitate tasks like , encapsulation, and directly in the database, reducing the need for external application code. Other databases offer similar extensions, such as in , which implements much of the SQL/PSM standard. PL/SQL, Oracle's procedural language extension, structures code into anonymous or named blocks that promote modularity and error management. A typical PL/SQL block consists of a DECLARE section for variable and exception declarations, a BEGIN section for executable statements, an optional EXCEPTION section for handling errors, and an END keyword to close the block. This structure supports conditional logic via and CASE statements, as well as iterative control through LOOP, , and constructs, allowing repetition based on conditions or predefined ranges. For instance, a simple might iterate over a range to process records:

plsql

DECLARE counter NUMBER := 0; BEGIN FOR i IN 1..5 LOOP counter := counter + i; END LOOP; END;

DECLARE counter NUMBER := 0; BEGIN FOR i IN 1..5 LOOP counter := counter + i; END LOOP; END;

Exception handling in PL/SQL uses predefined exceptions like NO_DATA_FOUND or user-defined ones declared in the DECLARE section, enabling graceful error recovery. T-SQL, Microsoft's extension for SQL Server, mirrors PL/SQL's procedural capabilities while introducing enhancements for robustness. It employs a similar block structure but emphasizes batch execution and integration with .NET via common language runtime (CLR). T-SQL supports conditionals through IF-ELSE and CASE expressions, and loops via WHILE statements, facilitating repetitive tasks like data transformation. A distinctive feature is the TRY-CATCH construct for error handling, which captures errors with severity greater than 10 that do not terminate the connection, allowing custom responses such as logging or rollback. An example TRY-CATCH block might look like:

sql

BEGIN TRY -- Executable statements, e.g., a risky division SELECT 1 / 0; END TRY BEGIN CATCH SELECT ERROR_MESSAGE() AS ErrorDetails; END CATCH;

BEGIN TRY -- Executable statements, e.g., a risky division SELECT 1 / 0; END TRY BEGIN CATCH SELECT ERROR_MESSAGE() AS ErrorDetails; END CATCH;

This mechanism improves code reliability by isolating error-prone operations. Stored procedures in these extensions encapsulate reusable SQL and procedural logic, defined using the CREATE PROCEDURE statement and invoked with EXECUTE or CALL. They accept input parameters, perform operations like data manipulation, and can return output via parameters or result sets, promoting by compiling once and executing multiple times. In Oracle and SQL Server T-SQL, procedures support transaction control and can be schema-qualified for . For example, a basic procedure to update employee salaries might be created as:

sql

CREATE PROCEDURE UpdateSalary @EmpID INT, @NewSalary DECIMAL(10,2) AS BEGIN UPDATE Employees SET Salary = @NewSalary WHERE EmployeeID = @EmpID; END;

CREATE PROCEDURE UpdateSalary @EmpID INT, @NewSalary DECIMAL(10,2) AS BEGIN UPDATE Employees SET Salary = @NewSalary WHERE EmployeeID = @EmpID; END;

Execution would then use: EXEC UpdateSalary 123, 75000;. This modularity enhances maintainability and security by centralizing logic. Functions in procedural extensions return computed values, categorized as scalar or table-valued. Scalar functions return a single value, such as a string or number, and are often used in SELECT clauses for calculations like formatting dates. Table-valued functions, in contrast, return a result set resembling a table, enabling their use in JOINs or as data sources for further querying; they can be inline (single SELECT) or multi-statement for complex logic. In T-SQL, for instance:

sql

CREATE FUNCTION GetEmployeeDetails (@DeptID INT) RETURNS TABLE AS RETURN (SELECT * FROM Employees WHERE DepartmentID = @DeptID);

CREATE FUNCTION GetEmployeeDetails (@DeptID INT) RETURNS TABLE AS RETURN (SELECT * FROM Employees WHERE DepartmentID = @DeptID);

This allows queries like SELECT * FROM GetEmployeeDetails(5);. Scalar functions, however, like one computing age from a birthdate, return one value per invocation: CREATE FUNCTION dbo.GetAge (@BirthDate DATE) RETURNS INT AS BEGIN RETURN DATEDIFF(YEAR, @BirthDate, GETDATE()); END;. These distinctions optimize performance, with table-valued functions generally preferred for set-based operations. Efforts to standardize procedural extensions culminated in SQL/PSM (Persistent Stored Modules), introduced in the SQL:1999 standard (ISO/IEC 9075-4:1999), which defines a portable syntax for stored procedures and functions using for local variables, BEGIN...END for blocks, and control structures like IF and LOOP. SQL/PSM aims to enable cross-database compatibility by specifying parameter modes (IN, OUT, INOUT), cursors, and handlers, though adoption varies, with vendors like DB2 and implementing subsets. This standard extends core SQL to support modular, without proprietary dialects.

Data Control Language (DCL) and Security

Data Control Language (DCL) encompasses SQL statements designed to manage access privileges and security within a database system, ensuring that users and roles can perform only authorized operations on database objects such as tables, views, and schemas. Introduced as part of the ANSI/ISO SQL standards, DCL commands like GRANT and REVOKE form the core mechanism for implementing fine-grained , preventing unauthorized data manipulation or exposure. These features are essential for maintaining and compliance in multi-user environments, where different principals require varying levels of permission. The GRANT statement assigns specific privileges to users, roles, or the group, allowing operations such as SELECT, INSERT, UPDATE, DELETE, or EXECUTE on database objects. For instance, the syntax GRANT SELECT ON employees TO user1; permits user1 to read data from the employees table without altering it. Privileges can be granted with the WITH GRANT OPTION clause, enabling the recipient to further delegate those permissions to others, which supports hierarchical access management in large systems. This command is compliant with ANSI/ISO SQL:2011, ensuring portability across conforming database management systems (DBMS). Conversely, the REVOKE statement withdraws previously granted privileges, immediately restricting access to specified objects. An example is REVOKE INSERT ON employees FROM user1;, which removes user1's ability to add records to the table. If privileges were granted with CASCADE, revoking them propagates the removal to any dependent grantees; otherwise, prevents revocation if dependencies exist. Like GRANT, REVOKE adheres to ANSI/ISO SQL:2011 standards, providing a standardized way to dynamically adjust permissions without altering underlying data structures. Roles in SQL serve as named groups of privileges, simplifying administration by allowing permissions to be bundled and assigned collectively to users. The CREATE ROLE statement defines a new , such as CREATE [ROLE](/page/Role) analyst;, after which privileges can be granted to the role using GRANT. Users are then assigned roles via GRANT analyst TO user1;, activating the associated permissions upon login or via SET ROLE. This mechanism, part of SQL:1999 (ISO/IEC 9075), reduces redundancy in privilege management and supports scalable security models in enterprise databases. Roles can also be nested, where one role inherits privileges from another, enhancing flexibility for complex organizational hierarchies. Database systems provide built-in security mechanisms beyond DCL, including authentication to verify user identity before privilege evaluation. In Microsoft SQL Server, Windows Authentication integrates with operating system credentials for seamless, secure logins without storing passwords in the database. This mode leverages Kerberos or NTLM protocols to authenticate users, reducing exposure to credential compromise compared to SQL Server Authentication, which uses database-stored usernames and passwords. Row-level security (RLS) extends by restricting operations to specific rows based on user context, often implemented through rather than coarse object-level grants. In , RLS is enabled on a table with ALTER TABLE employees ENABLE ROW LEVEL [SECURITY](/page/Security);, followed by definitions like CREATE [POLICY](/page/Policy) analyst_policy ON employees FOR SELECT USING (department = current_user);, which limits visibility to rows matching the user's department. This feature, introduced in 9.5, enforces at the query execution layer, complementing DCL by preventing data leaks even if broader privileges are granted. can apply to SELECT, INSERT, UPDATE, or DELETE, with permissive or restrictive modes to combine multiple rules. In implementations like SQL Server, introduced in 2008, auditing capabilities allow tracking of database access and modifications to detect unauthorized activities or support compliance. Audit specifications define events to monitor, such as logins or data changes, with actions grouped for efficiency. In implementations like SQL Server, database-level audit specifications target object-specific events, writing logs to files, the Windows Event Log, or security logs for review. This feature ensures comprehensive visibility into security-relevant operations without impacting query performance significantly.

Transaction Management

Transaction management in SQL provides mechanisms to group multiple operations into atomic units, ensuring and reliability in multi-user environments. These mechanisms allow database systems to handle concurrent access while maintaining consistency, particularly during failures or errors. SQL's transaction model supports the properties, which guarantee that transactions are processed reliably. The ACID properties—Atomicity, Consistency, Isolation, and —form the foundation of SQL transaction semantics. Atomicity ensures that a transaction is treated as a single, indivisible unit: either all operations succeed, or none are applied, preventing partial updates. Consistency requires that a transaction brings the database from one valid state to another, enforcing constraints such as primary keys and foreign keys. Isolation prevents concurrent transactions from interfering with each other, allowing them to operate as if executed sequentially despite parallelism. guarantees that once a transaction commits, its changes persist even in the event of system failures, typically achieved through and recovery protocols. SQL defines standard commands to control transactions explicitly. The BEGIN TRANSACTION (or START TRANSACTION) statement initiates a new transaction, grouping subsequent DML statements until termination. The COMMIT command finalizes the transaction, making all changes permanent and visible to other users. Conversely, ROLLBACK undoes all changes since the transaction began, reverting the database to its pre-transaction state. These commands are part of the core SQL standard and are implemented across major DBMSs to enforce atomicity and consistency. To manage concurrency, SQL specifies four isolation levels in the SQL:1992 standard, balancing performance and anomaly prevention. READ UNCOMMITTED permits dirty reads, where a transaction can view uncommitted changes from others, offering the lowest isolation but highest concurrency. READ COMMITTED prevents dirty reads by ensuring reads only see committed data, though it allows non-repeatable reads and phantoms. REPEATABLE READ avoids dirty and non-repeatable reads by locking read rows, but phantoms may still occur. SERIALIZABLE provides the strictest isolation, equivalent to serial execution, preventing all anomalies through full locking or equivalent mechanisms. Isolation levels are set via SET TRANSACTION ISOLATION LEVEL and help achieve the isolation property of . For finer control within long transactions, SQL supports savepoints using the SAVEPOINT command, introduced as a standard feature to enable partial rollbacks. A savepoint marks a point in the transaction; ROLLBACK TO SAVEPOINT undoes changes only up to that point, preserving earlier work, while RELEASE SAVEPOINT removes the marker. This allows nested recovery without full transaction abortion, enhancing flexibility in complex operations. Deadlock handling in SQL is primarily DBMS-specific, as the standard does not mandate a uniform approach. Most systems detect deadlocks using wait-for graphs or periodic lock monitoring; upon detection, one transaction is chosen as the victim, rolled back, and an is raised to the application. For example, SQL Server's deadlock monitor runs every 5 seconds by default, resolving cycles by terminating the transaction with the least cost estimated via a formula considering log space and undo work. employs similar graph-based detection during lock waits, prioritizing victim selection based on session age or resource usage to minimize impact. Applications must handle deadlock s by retrying transactions, often with .

Data Types and Storage

Predefined Data Types

SQL's predefined data types, as specified in the ISO/IEC 9075 standard, provide the fundamental building blocks for defining columns, variables, and literals in relational databases, ensuring portability across compliant implementations. These types are categorized into numeric, character string, binary string, datetime, interval, and , with each designed to handle specific kinds of while enforcing constraints on storage, precision, and operations. The standard mandates support for these types to promote , though exact storage sizes and additional behaviors may vary by implementation.

Numeric Types

Numeric types in SQL store , , or floating-point values, divided into exact and approximate categories to preserve precision or allow for efficient representation of real numbers. Exact numeric types include , which represents whole numbers with no and is typically implemented as a 32-bit signed ranging from -2,147,483,648 to 2,147,483,647, though the standard focuses on semantic rather than bit width. SMALLINT and BIGINT extend this for smaller and larger ranges, respectively, while (p,s) and NUMERIC(p,s) allow user-specified precision (p, total digits) and scale (s, digits after point) for , such as (10,2) for values up to 99999999.99. Approximate numeric types like FLOAT(p) and REAL use binary floating-point representation for high-speed calculations, where p denotes the precision in bits, but they may introduce errors unsuitable for financial applications.

Character String Types

Character string types manage textual data, supporting fixed-length, variable-length, and large-object storage to accommodate everything from short identifiers to extensive documents. CHAR(n) or CHARACTER(n) allocates a fixed n characters of storage, padding with spaces if needed, ideal for codes like country abbreviations where length is constant. or CHARACTER VARYING(n) stores up to n characters without padding, conserving space for variable-length strings such as names or addresses, with n often limited to 65,535 in practice. For oversized text, (Character Large Object) handles binary large objects exceeding typical string limits, up to gigabytes, enabling storage of articles or logs without length constraints. National character variants like NCHAR and NVARCHAR support for international text.

Date and Time Types

Datetime types capture temporal information, aligning with the and for consistent chronology across systems. DATE stores a year, month, and day (e.g., '2025-11-08'), spanning from 0001-01-01 to 9999-12-31. TIME(p) records hours, minutes, and seconds with optional fractional precision p (up to 6 digits for microseconds), such as '14:30:00.123456'. (p) combines DATE and TIME for full instants, like '2025-11-08 14:30:00.123456', and may include offsets in extended forms. These types, introduced in earlier standards and refined in SQL:1999, support arithmetic and comparisons for querying temporal data. INTERVAL qualifiers duration between points, such as YEAR TO MONTH or DAY TO SECOND, for expressions like 'INTERVAL 1 DAY'.

Binary String Types

Binary string types store sequences of bytes for non-textual data like images or encrypted content, distinct from character types by lacking encoding assumptions. BINARY(n) reserves fixed n bytes, similar to CHAR but without character interpretation. VARBINARY(n) holds variable-length binary data up to n bytes, efficient for hashes or keys. BLOB (Binary Large Object) accommodates massive binary payloads, such as files, without size limits in the standard, though implementations cap at terabytes. These types preserve exact byte sequences and support operations like .

Boolean Type

The BOOLEAN type, standardized in SQL:1999, represents logical values with literals TRUE, FALSE, or the null UNKNOWN, enabling conditional expressions in queries and procedural code. It occupies minimal storage, often a single bit or byte, and integrates with operators like AND, OR, and NOT for truth evaluation. Unlike numeric approximations, BOOLEAN enforces strict , crucial for decision-making in database constraints. While the ISO standard defines these core types, vendors extend them for specialized needs; for instance, introduces TINYINT as a 1-byte for compact storage of small values from -128 to 127 (signed) or 0 to 255 (unsigned). Similarly, provides UUID, a 128-bit type for universally unique identifiers formatted as 8-4-4-4-12 digits, enhancing distributed system uniqueness. These extensions are defined in statements like CREATE TABLE.

User-Defined and Complex Types

SQL supports user-defined types (UDTs) to extend the predefined data types, allowing users to create custom types with specific behaviors and constraints tailored to application needs. These mechanisms, introduced in SQL:1999, enable the definition of domains as aliases for existing types with added constraints and distinct types that enforce by preventing implicit conversions from their base types. The CREATE TYPE statement is used to define these, either standalone or within a creation. For example, a domain for email addresses might be created as CREATE DOMAIN email AS VARCHAR(255) CHECK (VALUE LIKE '%@%.%');, ensuring validation at the type level. Distinct types, also defined via CREATE TYPE, are based on built-in types but treated as unique for operations, promoting strong typing; for instance, CREATE TYPE money AS DECIMAL(10,2); distinguishes monetary values from general decimals, requiring explicit casting for assignments. This feature enhances by avoiding unintended arithmetic or comparisons between incompatible values. Unlike domains, distinct types support method definitions and can be used in table columns, parameters, or routines. Structured types in SQL:1999 allow composite data representation through row types, which aggregate multiple fields into a single value. A row type can be named using CREATE TYPE address AS ROW (street VARCHAR(100), city VARCHAR(50), zip INTEGER);, enabling structured storage for entities like addresses in columns or variables. These types support constructor functions for instantiation, such as address('123 Main St', 'Anytown', 12345), and can be nested or used in table definitions for object-relational mapping. Row types facilitate hierarchical data modeling without flattening into multiple columns. Collection types, including arrays and multisets, were added in SQL:1999 and SQL:2003, respectively, to handle variable-sized groupings of values. Arrays are ordered and fixed-size collections, declared as column_name INTEGER ARRAY[5], and support indexing like array_column[1] or construction via ARRAY[1, 2, 3]. Multisets, unordered and allowing duplicates, extend this for bag semantics, useful in aggregate queries or data import scenarios. Both can be used in table columns and manipulated with functions like CARDINALITY for size or set operations. SQL:2003 introduced built-in support for XML types via CREATE TYPE xml_type AS XML;, storing well-formed XML documents with validation against schemas and methods for querying or serialization, such as XMLSerialize or XMLQuery. This integrates semi-structured data into relational schemas, allowing XML columns in tables and functions like EXISTS NODE for XPath-based predicates. The type ensures type safety for XML operations, bridging relational and document-oriented paradigms. The SQL:2023 standard added JSON as a distinct data type, supporting storage, validation, and manipulation of JSON documents. Functions like JSON_VALUE extract scalars, JSON_QUERY retrieves objects or arrays, and JSON_MODIFY updates content, enabling hybrid relational-JSON workflows. For example, a column data JSON can hold {"name": "Alice", "age": 30}, queried via JSON_VALUE(data, '$.name'). This facilitates NoSQL-like flexibility within SQL environments. In implementations like PostgreSQL, object-oriented extensions allow custom composite types via CREATE TYPE point AS (x FLOAT, y FLOAT);, which can include methods and operators for domain-specific behavior, such as geometric calculations. These types support inheritance and can be used in arrays or as table row types, enhancing extensibility beyond the standard.

Handling Nulls and Duplicates

In SQL, null represents a special marker for unknown or missing data values, distinct from any actual value including zero or empty strings. This leads to a three-valued logic system in predicates and expressions, where results can be true, false, or unknown (often treated equivalently to false in WHERE clauses but distinct in other contexts). Null propagation occurs in comparisons, where any operation involving a null (e.g., column = null) evaluates to unknown rather than true or false, preventing unintended matches. In aggregate functions, nulls are generally ignored: for instance, COUNT(expression) excludes nulls while counting non-null values, SUM treats nulls as zero by skipping them, and AVG computes over non-null inputs only. This behavior ensures aggregates reflect meaningful data without distortion from absences, though an empty input set (no rows) typically yields null for most aggregates except COUNT(*), which returns zero. To explicitly test for nulls, SQL provides the IS NULL and IS NOT NULL operators, which return true or false without invoking —unlike equality checks. For substituting defaults, the standard COALESCE function returns the first non-null argument from a list, or null if all are null; for example, COALESCE(column1, column2, 'default') handles missing values in queries. Duplicates in query results arise from repeated row values and are managed using the DISTINCT keyword in SELECT statements, which eliminates identical rows from the output set. The GROUP BY clause further handles duplicates by partitioning rows into groups based on specified columns, often combined with aggregates to produce one row per unique combination. At the schema level, a UNIQUE constraint in (DDL) enforces no duplicate values in specified columns during inserts or updates, rejecting violations to maintain , though it allows multiple nulls since nulls are not considered equal. The following example illustrates null handling:

sql

SELECT COALESCE(salary, 0) AS adjusted_salary FROM employees WHERE department IS NOT NULL;

SELECT COALESCE(salary, 0) AS adjusted_salary FROM employees WHERE department IS NOT NULL;

This query substitutes 0 for null salaries and filters non-null departments. For duplicates:

sql

SELECT DISTINCT department FROM employees;

SELECT DISTINCT department FROM employees;

This returns unique department names, removing repeats.

Advanced Querying Techniques

Joins and Subqueries

In SQL, joins are operations that combine rows from two or more tables based on related columns, enabling the retrieval of data across relational structures. The standard introduced explicit join syntax using the JOIN keyword and an ON clause to specify join conditions, replacing older implicit joins in the WHERE clause for better clarity and handling of outer joins. This syntax allows for precise control over which rows are included in the result set. The primary join types defined in the SQL-92 standard are INNER JOIN, OUTER JOIN variants (LEFT, RIGHT, and FULL), and CROSS JOIN. An INNER JOIN returns only rows where there is a match in both tables based on the ON condition, such as SELECT e.name, d.department_name FROM Employees e INNER JOIN Departments d ON e.dept_id = d.id, which retrieves employee names and their department names only for matching department IDs. LEFT OUTER JOIN includes all rows from the left table and matching rows from the right table, filling non-matches with NULLs in the right table's columns; for example, the above query with LEFT JOIN would show all employees, even those without assigned departments. RIGHT OUTER JOIN mirrors this but prioritizes the right table, while FULL OUTER JOIN includes all rows from both tables with NULLs for non-matches, though support for FULL OUTER JOIN varies across implementations as it is not universally required by the standard. CROSS JOIN produces a , pairing every row from the first table with every row from the second without a condition, resulting in m * n rows for tables of sizes m and n; it is useful for generating combinations but can produce large result sets. Subqueries, also known as nested queries, allow embedding one SELECT statement within another to perform complex filtering or computation. They are classified by their return value: scalar subqueries return a single value, row subqueries return a single row with multiple columns, and table subqueries return multiple rows and columns. Subqueries can appear in the SELECT list for computed columns, such as SELECT name, (SELECT AVG(salary) FROM Employees) AS avg_salary FROM Employees, yielding the average salary alongside each employee's name; in the WHERE clause for filtering, like SELECT * FROM Employees WHERE salary > (SELECT AVG(salary) FROM Employees), which finds employees above average salary; or in the FROM clause as a derived table, e.g., SELECT * FROM (SELECT * FROM Employees WHERE dept_id = 1) AS dept1_employees. Correlated subqueries reference columns from the outer query, making them execute once per outer row and dependent on its context. For instance, SELECT name FROM Employees e WHERE salary > (SELECT AVG(salary) FROM Employees e2 WHERE e2.dept_id = e.dept_id) identifies employees with salaries above their department's average, as the inner query correlates on dept_id. This differs from non-correlated subqueries, which run independently once. For performance, indexes on join columns accelerate matching by reducing scan times, and the query optimizer selects algorithms like nested loops for indexed small-to-large joins, merge joins for sorted data, or hash joins for large unsorted sets. Correlated subqueries may incur overhead from repeated execution, but optimizers often rewrite them as joins for efficiency.

Window Functions and Aggregations

Window functions, also known as analytic functions, enable computations across a set of rows related to the current row without collapsing the result set into groups, allowing for advanced analytical queries such as ranking, running totals, and moving averages. These functions were formally introduced in the standard (ISO/IEC 9075-2:2003), with subsequent enhancements in SQL:2008 and later revisions to support more flexible window framing and grouping options. Unlike traditional aggregate functions that require a GROUP BY clause to summarize data, window functions preserve all rows in the output while adding computed values, making them essential for in relational databases. The core syntax for window functions involves an OVER clause that defines the window for the computation, typically structured as OVER (PARTITION BY column ORDER BY column [frame_specification]). The PARTITION BY clause divides the result set into partitions (subsets of rows) based on one or more columns, similar to GROUP BY but without aggregation ; if omitted, the entire result set forms a single partition. The ORDER BY clause within OVER sorts rows within each partition, which is required for functions and influences the frame for ordered aggregates; it supports ascending or descending order, with options for handling nulls. The optional frame specification, introduced and refined in SQL:2003 and SQL:2008, delimits the rows considered in the window using ROWS, RANGE, or GROUPS modes to specify boundaries like UNBOUNDED PRECEDING, CURRENT ROW, or value-based offsets. Ranking functions such as ROW_NUMBER() and RANK() assign sequential numbers or ranks to rows within a partition, ordered by specified criteria. For example, to rank sales records by amount within each region, a query might use SELECT region, salesperson, sales_amount, ROW_NUMBER() OVER (PARTITION BY region ORDER BY sales_amount DESC) AS rank FROM sales_table;, which assigns unique numbers starting from 1 to each row per region, preserving all original rows. RANK() behaves similarly but assigns the same rank to tied values and skips subsequent numbers (e.g., 1, 2, 2, 4), useful for identifying top performers without gaps. Aggregate window functions extend standard aggregates like SUM(), AVG(), and COUNT() over a window to compute values such as running totals or moving averages while retaining row-level detail. For running totals, SUM(sales_amount) OVER (PARTITION BY region ORDER BY sale_date ROWS UNBOUNDED PRECEDING) calculates the cumulative sum from the partition start to the current row for each sale. Moving averages can be computed using frame specifications, such as AVG(sales_amount) OVER (ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW) to average the current and two prior values, enabling without subqueries. Frame specifications provide precise control over the boundaries, with ROWS defining physical offsets (e.g., number of rows) and RANGE using logical offsets based on the ORDER BY values (e.g., values within a time range). Common frames include ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW for cumulative computations from the partition's start, or ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING for centered moving windows; the default frame is RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW, which includes all rows from the start up to peers of the current row. These options, expanded in SQL:2008, allow for efficient handling of time-series data, such as cumulative sums in financial reporting. A key distinction from GROUP BY is that window functions operate on the full result set post-filtering and joining, applying computations per row without reducing the output cardinality, whereas GROUP BY aggregates rows into summary groups, eliminating individual details. This row-preserving behavior enables complex analytics in a single query, avoiding the need for multiple self-joins or subqueries that GROUP BY alone would require for similar results.

Common Table Expressions (CTEs)

Common Table Expressions (CTEs) are temporary named result sets defined within the scope of a single SQL statement, allowing for more modular and readable query construction by breaking down complex logic into reusable components. Introduced as part of the SQL:1999 standard, CTEs use the WITH clause to define one or more subqueries that can be referenced in the main query, improving maintainability without creating permanent objects in the database. The basic syntax for a CTE is WITH cte_name [(column_list)] AS (subquery) statement, where the statement is typically a SELECT, INSERT, UPDATE, or DELETE that references the CTE. Non-recursive CTEs enhance query readability by substituting for subqueries or views in multi-step computations, such as generating reports that involve intermediate aggregations. For instance, a CTE can first compute total sales by region and then use that result to filter top-performing areas in the outer query, avoiding nested subqueries and making the logic easier to follow. This approach is particularly useful in analytical queries where breaking down steps clarifies intent without impacting the overall execution plan in most database management systems (DBMS). Recursive CTEs, also standardized in SQL:1999, extend this capability to handle hierarchical or tree-structured data by allowing the CTE to reference itself through a UNION ALL construct, enabling iterative expansion until a termination condition is met. The structure typically includes an member (initial query) followed by a recursive member that joins back to the CTE, as in WITH RECURSIVE cte_name (columns) AS (anchor_query UNION ALL recursive_query) SELECT ... FROM cte_name. A common application is traversing an employee reporting : the anchor selects top-level managers, and the recursive part appends subordinates by joining on the manager ID column, producing a complete organizational . Another representative example is a (BOM) explosion, where the anchor identifies root assemblies and the recursive member unfolds component subassemblies level by level, revealing the full for or . This recursion supports basic patterns, such as path finding in networks, by accumulating paths or levels in additional columns during . Despite their benefits, CTEs have limitations that vary by DBMS implementation. In some systems like , non-recursive CTEs are materialized—computed once and stored temporarily—which can lead to unnecessary computation if the result is referenced multiple times without optimization, potentially degrading performance for large datasets. Recursive CTEs may also face depth limits (e.g., 100 levels in SQL Server) to prevent infinite loops, and their optimization relies on the query planner, which might not inline them as efficiently as equivalent subqueries in all cases. Additionally, CTEs cannot have indexes or constraints applied directly, limiting their use in scenarios requiring temporary table-like persistence.

Distributed and Extended SQL

Distributed Query Processing

Distributed query processing in SQL enables the execution of queries across multiple nodes or databases, facilitating in large-scale relational systems by distributing data and computation. This approach addresses the limitations of single-node databases by partitioning workloads, allowing for parallel execution and improved throughput. In environments, query optimizers generate execution plans that involve data movement, local on , and result aggregation at a coordinator node. Systems like SQL and distributed RDBMS such as or Oracle Sharding implement these mechanisms to handle high-volume queries efficiently. Sharding, or horizontal partitioning, is a core technique in where large tables are divided into smaller, self-contained subsets called , each stored on separate servers to balance load and enhance . is typically partitioned using a shard key—such as a hash of a column value or a range—to ensure even distribution across nodes; for instance, hash sharding in maps keys to one of 64,000 tablets via a ranging from 0x0000 to 0xFFFF. Queries targeting sharded involve shard , where the optimizer identifies relevant to minimize scanned, followed by parallel execution on each and aggregation of results. This method improves performance by reducing contention and allowing linear scaling with added nodes, though it requires careful key selection to avoid hotspots. Sharding, for example, processes multi-shard queries by rewriting them into independent subqueries executed on each , maintaining consistency via a global system change number (SCN). Distributed joins in SQL systems like extend traditional join operations across clusters by employing strategies that account for data locality and network costs. The , Spark's default for equi-joins on large datasets, involves shuffling both relations by join keys, sorting partitions on each node, and merging matching records in a distributed manner to produce the final result. For cases where one relation is small, the broadcast replicates the smaller table to all nodes, building local hash tables for efficient probing against the larger, unshuffled table, thus avoiding costly shuffles. Shuffle hash joins, an adaptive alternative, partition data by keys and build in-memory hash tables post-shuffle, converting to sort-merge if partitions exceed size thresholds (e.g., via spark.sql.adaptive.maxShuffledHashJoinLocalMapThreshold). These strategies optimize for cluster resources, with broadcast joins triggered automatically for tables under 10 MB by default. SQL standards and extensions support distributed querying through features like federated tables, which allow transparent access to remote data sources. In , the FEDERATED storage engine enables creation of local tables that proxy remote MySQL tables, executing queries by forwarding them over a network connection without storing data locally; for example, a CREATE TABLE statement includes a CONNECTION string specifying the remote host, user, and database. This facilitates distributed queries across heterogeneous or remote instances, though it requires enabling the engine via server startup options like --federated and incurs network overhead for each operation. Extensions to the SQL standard, such as the interface, incorporate two-phase commit (2PC) for coordinating distributed transactions, ensuring atomicity by dividing the process into a prepare phase—where participants vote on commit readiness—and a commit phase—where the coordinator broadcasts the decision, with all nodes logging outcomes to handle failures. 2PC, originally formalized in systems like NonStop SQL, guarantees that transactions either commit fully or abort entirely across nodes, though it introduces coordinator bottlenecks. Challenges in distributed SQL query processing stem primarily from network latency and fault tolerance requirements. Data movement across nodes, such as during shuffles or federated queries, amplifies latency, potentially degrading performance for latency-sensitive applications; mitigation involves optimizing join strategies to minimize transfers, like preferring broadcast over shuffle when feasible. is achieved through replication, where data are duplicated across nodes (e.g., synchronous or asynchronous modes) to ensure during failures, but this trades off consistency and added overhead—synchronous replication reduces latency variance at the cost of throughput. Systems balance these via configurable consistency levels, such as Oracle's MULTISHARD_QUERY_DATA_CONSISTENCY parameter, which allows trading freshness for speed in read-heavy workloads.

SQL in NoSQL and Hybrid Systems

In non-relational and hybrid database environments, SQL adaptations enable querying diverse data stores while leveraging familiar relational paradigms, bridging the gap between structured querying and scalable, schema-flexible architectures. These adaptations often involve query languages or engines that translate SQL-like constructs into underlying or distributed processing operations, facilitating analytics on large-scale, heterogeneous data without full relational enforcement. SQL-on-Hadoop systems exemplify early efforts to apply SQL to non-relational frameworks. , introduced in 2008 by and later donated to , provides HiveQL, a SQL-like language that compiles queries into jobs for processing structured data stored in Hadoop's HDFS. This approach allows users to perform data warehousing tasks, such as ETL and ad-hoc querying, on petabyte-scale datasets without rewriting applications in lower-level paradigms like Java . Similarly, Presto, open-sourced in 2013 by , serves as a query engine optimized for interactive analytics across federated data sources, including Hadoop, supporting low-latency queries on diverse formats like and without materializing intermediate results. NewSQL systems extend SQL compatibility into distributed, non-relational contexts by combining transactions with horizontal scalability. , launched as an open-source project in 2015, implements a database inspired by Google's Spanner, using a key-value store foundation to ensure serializable isolation and fault tolerance across clusters while supporting standard wire protocol for seamless application migration. , released in 2016 by PingCAP, offers MySQL-compatible with strong consistency guarantees, separating compute and storage layers to handle both OLTP and OLAP workloads on commodity hardware. These systems prioritize relational semantics in hybrid setups, enabling geo-distributed deployments without sacrificing transactional integrity. NoSQL databases incorporate SQL layers to enhance query expressiveness while retaining non-relational benefits like schema flexibility. Apache Cassandra's Cassandra Query Language (CQL), introduced in 2011, provides a SQL-inspired syntax for defining tables, inserting data, and executing SELECT statements on its , though limited to partition-key-based access patterns to maintain . MongoDB's , added in version 2.2 in 2012, emulates SQL aggregation through a sequence of stages like $match (for filtering), $group (for grouping and aggregation), and $project (for projection), allowing complex data transformations on document collections without joins, thus mimicking GROUP BY and HAVING clauses in a denormalized environment. Hybrid systems yield benefits such as combining schema evolution from with SQL's declarative querying, reducing developer friction in scenarios. For instance, , launched in 2012 as a fully managed , employs PostgreSQL-compatible SQL on columnar storage integrated with S3 for petabyte-scale analytics, enabling hybrid workloads that blend relational queries with ingestion. This familiarity accelerates adoption in environments mixing OLAP with lakes. However, trade-offs persist between consistency models and performance. NoSQL SQL layers often embrace for availability and partition tolerance under constraints, potentially leading to stale reads during network partitions, whereas NewSQL hybrids like CockroachDB enforce via consensus protocols like , incurring higher latency for strict isolation. These choices balance against reliability, with hybrid designs favoring tunable consistency to suit application needs.

Object-Relational and Spatial Extensions

SQL:1999 introduced object-relational features to enhance the relational model with object-oriented capabilities, including user-defined types (UDTs) that allow structured types with attributes and methods, and reference (REF) types that act as pointers to rows in typed tables. REF types enable the creation of relationships between objects by referencing instances in other tables, supporting dereferencing operations to access related data directly. UDTs can define methods, such as observer methods like EQUAL and LESSTHAN, which operate on instances of the type to compare or manipulate object states. Commercial implementations extended these concepts; for instance, 's ANYDATA type, introduced in Oracle 9i, provides a self-describing container that can hold instances of any built-in or user-defined type along with its type descriptor, facilitating dynamic handling of heterogeneous data. implements table inheritance through the INHERITS clause in CREATE TABLE, allowing child tables to automatically include columns and constraints from a parent table, enabling hierarchical where queries on the parent can transparently access data from subtypes. For spatial data, the SQL/MM Spatial standard (ISO/IEC 13249-3) defines a framework for managing geospatial information within SQL databases, introducing geometry types such as ST_Point, ST_LineString, and ST_Polygon to represent spatial objects. It specifies routines like ST_Distance, which computes the shortest distance between two geometries, and ST_Intersects, which determines if two spatial objects overlap—essential for (GIS) queries, such as identifying parcels intersecting a given boundary. A prominent vendor extension is , released in 2001 by Refractions Research as an add-on to , which implements SQL/MM Spatial alongside Open Geospatial Consortium standards, adding support for spatial indexing via GiST and advanced functions for raster and vector data analysis.

Alternatives and Criticisms

Alternative Query Languages

provides the theoretical foundation for SQL, consisting of primitive operations such as selection (σ), projection (π), and join (⋈) that enable the manipulation and querying of relational data. These operations form the mathematical basis upon which SQL queries are constructed, translating declarative statements into executable plans. However, expressions are often verbose and require explicit specification of intermediate results, making them less practical for direct user interaction compared to SQL's more concise syntax. Query-by-Example (QBE) emerged as a visual alternative to textual query languages in the 1970s, developed by Moshe M. Zloof at and first described in 1977. QBE allows users to construct queries by filling in a skeletal table template with example values or conditions, facilitating intuitive without writing code; for instance, entering a partial row like "Smith" under a "Name" column retrieves matching records. This approach was later adopted in tools like , where the query grid implements QBE principles to simplify database interactions for non-programmers. In environments, domain-specific languages have arisen to handle non-relational data structures more naturally. Cypher, introduced by in 2011, is a declarative tailored for property graphs, using ASCII-art patterns like MATCH (a:Person)-[:KNOWS]->(b:Person) RETURN a.name to traverse nodes and relationships efficiently. Similarly, 's (ArangoDB Query Language), designed for multi-model databases supporting documents, graphs, and key-value stores, extends SQL-like syntax with operations for heterogeneous data, such as FOR doc IN documents FILTER doc.type == "graph" RETURN doc. Modern alternatives integrate query capabilities directly into programming languages. (), released by in 2007 as part of C# 3.0 and .NET Framework 3.5, embeds SQL-like expressions within code using syntax like from p in products where p.Price > 10 select p, enabling type-safe queries over in-memory collections, databases, or XML without context switching. SQL's declarative nature, where users specify what data is desired without detailing how to retrieve it, contrasts with alternatives like , another declarative logic-based language that excels in recursive queries over deductive databases using rules such as ancestor(X,Y) :- parent(X,Y). ancestor(X,Z) :- parent(X,Y), ancestor(Y,Z). While both avoid procedural steps, Datalog's rule-oriented approach offers greater expressiveness for inference-heavy tasks, though it lacks SQL's widespread optimization for large-scale relational storage and joins. In visual or embedded contexts like QBE and , alternatives prioritize usability over SQL's standardized verbosity, whereas graph-focused languages like Cypher emphasize structural traversal beyond flat relations.

Design and Theoretical Criticisms

SQL's design has been subject to theoretical criticisms since its early development, primarily for deviating from the principles of the proposed by E.F. Codd and for introducing inconsistencies that hinder expressiveness and reliability. Critics argue that while SQL aimed to provide a user-friendly interface to relational databases, its ad hoc features and implementation compromises resulted in a that is neither fully orthogonal nor complete, leading to unnecessary complexity in query formulation. These flaws stem from SQL's origins in the 1970s System R project at , where practical usability often trumped theoretical purity. A key issue is SQL's non-orthogonality, where features overlap redundantly or inconsistently, violating the principle that language constructs should be independent and composable without side effects. For instance, the FULL OUTER JOIN operation can be simulated using a UNION of LEFT OUTER JOIN and RIGHT OUTER JOIN results, rendering the dedicated FULL OUTER JOIN syntax superfluous and increasing the risk of inconsistent implementations across dialects. Similarly, table expressions lack recursive nesting; a query like SELECT EMP# FROM (NYC UNION SFO) must be rewritten as SELECT EMP# FROM NYC UNION SELECT EMP# FROM SFO, breaking the expected closure of relational operations. Built-in functions exacerbate this, as aggregates like SUM cannot directly nest over subqueries without awkward reformulations, limiting modularity. These redundancies stem from SQL's piecemeal , making the language harder to learn and extend. SQL also suffers from a lack of completeness in supporting core relational operations, requiring vendor-specific extensions for full expressiveness. It does not natively provide INTERSECT or EXCEPT set operators in early standards, forcing users to emulate them via subqueries or JOINs, which undermines closure. Moreover, SQL lacks built-in support for certain relational concepts like explicit foreign keys or domain constraints beyond basic types, compelling extensions such as CHECK constraints or procedural code to enforce integrity. This incompleteness means simple relational tasks, like computing set differences without duplicates, demand verbose workarounds, deviating from the model's goal of universal operability on relations. Standardization efforts have added some operators in later versions (e.g., SQL:1999), but core gaps persist without full adherence to relational theory. The verbosity of SQL queries represents another theoretical shortcoming, as even straightforward operations require excessive syntax that amplifies the potential for errors. Basic table retrieval mandates SELECT * FROM T rather than simply T, and aggregations demand repeating grouped attributes in both SELECT and GROUP BY clauses, such as SELECT r_regionkey, r_name, COUNT(*) FROM region GROUP BY r_regionkey, r_name. Window functions lack a direct filtering mechanism akin to HAVING for groups, necessitating subqueries for post-window filtering, as in SELECT o_custkey, rk FROM (SELECT o_custkey, RANK() OVER (ORDER BY o_totalprice) rk FROM orders) t WHERE rk < 4. This prolixity, driven by SQL's ambition for declarative readability, instead burdens users with boilerplate, increasing cognitive load and error rates in complex queries. With over 600 keywords in recent implementations like PostgreSQL (as of version 18), the language's bulk further complicates mastery. Historical baggage in SQL manifests as reserved words and legacy syntax that conflict with user identifiers, reflecting compromises from its codename origins and early hardware constraints. Words like SELECT, ORDER, and GROUP are , requiring delimiters (e.g., double quotes or brackets) for use as table or column names, such as CREATE TABLE "order" (...), which disrupts natural naming and portability across dialects. This issue arises from SQL's evolution without a clean slate, where keywords accumulated without , leading to conflicts in real-world schemas. The uppercase convention for keywords, a holdover from terminals lacking lowercase support, adds to the perception of an outdated design. Finally, SQL deviates from Codd's relational rules, particularly Rule 5, which mandates a comprehensive sublanguage supporting , manipulation, view , constraints, and in both interactive and programmatic modes with linear syntax. While SQL provides DDL and DML via standalone and embedded forms, it falls short on uniform view —rules are , allowing updates only for simple views and prohibiting them for aggregates without extensions—and lacks native enforcement of relational like foreign keys. Codd himself viewed SQL as flawed for permitting duplicates and incomplete support, compromising the model's logical foundation.

Practical Limitations and Impedance Mismatch

The object-relational impedance mismatch arises from fundamental differences between the used in SQL databases and the object-oriented prevalent in modern application development languages. In relational databases, data is organized into tables with rows and columns, enforcing normalization to avoid redundancy, whereas object-oriented programs represent data as interconnected objects with , encapsulation, and polymorphism. This gap complicates the mapping of complex object hierarchies to flat table structures, often requiring manual conversions that increase development effort and introduce errors. A prominent example of this mismatch is the handling of one-to-many relationships: an object might contain a collection of child objects, but in SQL, these must be queried separately from parent records, leading to fragmented data access patterns. differences further exacerbate the issue, as objects may aggregate data from multiple tables, while in OOP lacks direct equivalents in relational schemas without complex joins or single-table inheritance strategies. These discrepancies result in for and deserialization, hindering productivity in applications built with languages like or C#. The N+1 query problem exemplifies a practical bottleneck stemming from this mismatch, particularly in object-relational mapping (ORM) tools. When an application fetches a list of N parent entities and then iterates over them to load associated child entities , it executes one initial query followed by N additional queries—one per parent—resulting in excessive database round-trips and degraded throughput. In Hibernate, for instance, default of associations like @ManyToOne or @OneToMany triggers this issue unless explicitly mitigated, potentially multiplying query overhead in loops over result sets. SQL's emphasis on ACID (Atomicity, Consistency, Isolation, Durability) properties ensures transactional integrity but poses challenges for horizontal scalability in distributed environments. Traditional relational databases are optimized for vertical scaling via larger hardware, as ACID compliance relies on centralized locking and two-phase commits that become inefficient across multiple nodes without partitioning. Achieving horizontal scaling often requires manual sharding—dividing data across independent database instances—which complicates cross-shard transactions and can violate isolation guarantees unless using advanced techniques like distributed consensus protocols. For example, Sharding maintains ACID while enabling linear scalability, but it demands careful shard key selection to minimize inter-shard joins. Performance pitfalls in SQL queries frequently stem from unintended Cartesian products and index misuse, amplifying resource consumption. A Cartesian product occurs when joins lack proper conditions, producing the cross-product of row counts from involved tables—for instance, joining two tables with 1,000 rows each without an ON clause yields 1,000,000 rows, overwhelming memory and execution time. Missing explicit join predicates, such as omitting WHERE filters in multi-table queries, can inadvertently cause this explosion, as seen in legacy code or ad-hoc reports. Index misuse compounds these issues by failing to accelerate query paths effectively. Creating indexes on low-selectivity columns or neglecting composite indexes for frequent join conditions leads to full table scans, where the database reads unnecessary data rows. For example, indexing only a single column in a multi-column WHERE forces sequential scans instead of index seeks, inflating I/O costs; recommendations include analyzing query patterns with tools like execution plans to target high-cardinality columns. To mitigate these limitations, ORMs such as and Hibernate abstract the impedance mismatch by automating object-to-table mappings and providing mechanisms to optimize queries. reduces the paradigm gap through features like LINQ-to-SQL translation, which generates efficient parameterized queries and supports eager loading via Include() to preempt issues. Similarly, query planners in modern DBMS, such as PostgreSQL's genetic query optimizer, automatically select optimal execution paths, including hash joins to avoid Cartesian products and index-only scans for better performance. These tools, when configured with fetch strategies like JOIN FETCH in Hibernate, enable developers to balance usability and efficiency without raw SQL verbosity.

References

  1. https://www.ibm.com/think/topics/structured-query-language
  2. https://blog.ansi.org/ansi/sql-standard-iso-iec-9075-2023-ansi-x3-135/
  3. https://dl.acm.org/doi/10.1145/362384.362685
  4. https://www.ibm.com/history/relational-database
  5. https://docs.oracle.com/en/database/oracle/oracle-database/18/cncpt/introduction-to-oracle-database.html
  6. https://www.oracle.com/database/50-years-relational-database/
  7. https://www.ibm.com/new/announcements/celebrating-30-years-of-db2-running-the-worlds-mission-critical-workloads
  8. https://www.dbta.com/Columns/DBA-Corner/A-Short-History-of-DB2-for-z-OS-99183.aspx
  9. https://www.microsoft.com/en-us/sql-server/blog/2012/02/15/new-video-the-history-of-sql-server/
  10. https://learn.microsoft.com/en-us/sql/sql-server/what-is-sql-server?view=sql-server-ver17
  11. https://www.postgresql.org/docs/current/history.html
  12. https://blogs.oracle.com/mysql/post/mysql-retrospective-the-early-years
  13. https://learnsql.com/blog/history-of-sql-standards/
  14. https://www.oreilly.com/library/view/sql-in-a/9780596155322/ch01s02.html
  15. https://s3.amazonaws.com/files.inductiveautomation.com/s3fs-staging/test_folder/SQL-The-Next-Big-Thing-in-SCADA.pdf
  16. https://www.cockroachlabs.com/blog/history-of-databases-distributed-sql/
  17. https://www.usenix.org/system/files/login/articles/zaharia.pdf
  18. https://neo4j.com/blog/developer/gql-sql-history/
  19. https://modern-sql.com/blog/2017-06/whats-new-in-sql-2016
  20. http://peter.eisentraut.org/blog/2023/04/04/sql-2023-is-finished-here-is-whats-new
  21. https://engineering.fb.com/2009/06/10/web/hive-a-petabyte-scale-data-warehouse-using-hadoop/
  22. https://people.csail.mit.edu/matei/papers/2015/sigmod_spark_sql.pdf
  23. https://www.postgresql.org/files/documentation/pdf/7.2/tutorial-7.2-A4.pdf
  24. https://cloud.google.com/blog/products/data-analytics/new-blog-series-bigquery-explained-overview
  25. https://docs.aws.amazon.com/athena/latest/ug/what-is.html
  26. https://jtc1info.org/technology/subcommittees/data-mgmt-and-interchange/database-languages/
  27. https://sigmodrecord.org/?smd_process_download=1&download_id=6083
  28. https://s3.amazonaws.com/artifacts.opencypher.org/website/materials/SQLStandards_2017-10-20.pdf
  29. https://celerdata.com/glossary/ansi-sql
  30. https://www.postgresql.org/docs/current/features.html
  31. https://www.dbvis.com/thetable/standard-ansi-sql-what-it-is-and-why-it-matters/
  32. https://tdan.com/is-sql-a-real-standard-anymore/4923
  33. https://www.w3.org/Data/events/data-ws-2019/assets/slides/KeithWHare-2.pdf
  34. https://www.iso.org/standard/76583.html
  35. https://blogs.oracle.com/sql/general-availability-of-the-sql2023-standard
  36. https://modern-sql.com/caniuse/F313
  37. https://www.postgresql.org/about/news/postgresql-181-177-1611-1515-1420-and-1323-released-3171/
  38. https://support.oracle.com/knowledge/Oracle%20Database%20Products/742060_1.html
  39. https://blogs.oracle.com/database/post/oracle-database-23c-the-next-long-term-support-release
  40. https://docs.oracle.com/en/database/oracle/oracle-database/19/drdaa/glossary.html
  41. https://docs.oracle.com/en/database/oracle/oracle-database/26/drdaa/SQL-translation-framework-overview.html
  42. https://docs.oracle.com/en/database/oracle/oracle-database/21/sqlrf/Oracle-Compliance-with-Older-Standards.html
  43. https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level?view=sql-server-ver17
  44. https://www.datacamp.com/tutorial/sql-date-greater-than
  45. https://www.petefreitag.com/blog/sql-pagination-limit-offset/
  46. https://docs.oracle.com/en/database/oracle/oracle-database/26/adfns/regexp.html
  47. https://learn.microsoft.com/en-us/sql/relational-databases/regular-expressions/overview?view=sql-server-ver17
  48. https://mimo.org/glossary/sql/regex
  49. https://www.sqlalchemy.org/features.html
  50. https://learn.microsoft.com/en-us/azure/dms/migration-using-azure-data-studio
  51. https://cloud.google.com/database-migration/docs/sqlserver/scenario-overview
  52. https://www.dbsofts.com/articles/sqlite_to_db2/
  53. https://docs.cloud.google.com/sql/docs/mysql/flags
  54. https://s3.us.cloud-object-storage.appdomain.cloud/res-files/2705-sequel-1974.pdf
  55. https://www.cs.cornell.edu/projects/btr/bioinformaticsschool/slides/gehrke.pdf
  56. https://www3.cs.stonybrook.edu/~kifer/Courses/cse532/slides/ch5.pdf
  57. https://bytes.usc.edu/cs585/s23-da-taaa/lectures/PerfTuning/misc/SQL_for_MySQLDevs.pdf
  58. https://learn.microsoft.com/en-us/sql/t-sql/statements/statements?view=sql-server-ver16
  59. https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-table-transact-sql?view=sql-server-ver16
  60. https://modern-sql.com/standard/parts
  61. https://www.postgresql.org/docs/current/sql-insert.html
  62. https://www.postgresql.org/docs/current/sql-update.html
  63. https://www.postgresql.org/docs/current/sql-delete.html
  64. https://www.dbvis.com/thetable/how-to-use-merge-in-sql-query-statements-complete-guide/
  65. https://www.postgresql.org/docs/current/sql-merge.html
  66. https://docs.oracle.com/en/database/oracle/oracle-database/23/lnpls/main-features-pl-sql.html
  67. https://learn.microsoft.com/en-us/sql/t-sql/language-elements/try-catch-transact-sql?view=sql-server-ver17
  68. https://www.postgresql.org/docs/current/plpgsql.html
  69. https://docs.oracle.com/database/121/LNPLS/controlstatements.htm
  70. https://learn.microsoft.com/en-us/sql/t-sql/statements/create-procedure-transact-sql?view=sql-server-ver17
  71. https://learn.microsoft.com/en-us/sql/relational-databases/user-defined-functions/user-defined-functions?view=sql-server-ver17
  72. https://old.dbs.uni-leipzig.de/files/lehre/sql99-eisenberg-melton-sigmod-record99.pdf
  73. https://www.iso.org/standard/29864.html
  74. https://docs.teradata.com/r/Enterprise_IntelliFlex_VMware/SQL-Data-Control-Language/Statement-Syntax/REVOKE
  75. https://docs.teradata.com/r/Enterprise_IntelliFlex_VMware/SQL-Data-Definition-Language-Syntax-and-Examples/User-Profile-and-Role-Statements/CREATE-ROLE
  76. https://learn.microsoft.com/en-us/sql/relational-databases/security/choose-an-authentication-mode?view=sql-server-ver17
  77. https://www.postgresql.org/docs/current/ddl-rowsecurity.html
  78. https://www.postgresql.org/docs/current/sql-createpolicy.html
  79. https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine?view=sql-server-ver17
  80. https://jimgray.azurewebsites.net/papers/theTransactionConcept.pdf
  81. https://dl.acm.org/doi/pdf/10.1145/122140.122149
  82. https://dev.mysql.com/doc/en/commit.html
  83. https://dev.mysql.com/doc/refman/en/innodb-transaction-isolation-levels.html
  84. https://www.postgresql.org/docs/current/sql-savepoint.html
  85. https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-deadlocks-guide?view=sql-server-ver17
  86. https://web.cecs.pdx.edu/~len/sql1999.pdf
  87. https://www.postgresql.org/docs/current/datatype-uuid.html
  88. https://sql-99.readthedocs.io/en/latest/chapters/27.html
  89. https://sql-99.readthedocs.io/en/latest/chapters/11.html
  90. https://www.oracle.com/technetwork/database/application-development/sql-2003-twp-129141.pdf
  91. https://sigmodrecord.org/publications/sigmodRecord/0409/11.JimMelton.pdf
  92. https://www.postgresql.org/docs/current/sql-createtype.html
  93. https://www.postgresql.org/docs/current/functions-conditional.html
  94. https://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
  95. https://dev.mysql.com/doc/refman/8.4/en/join.html
  96. https://learn.microsoft.com/en-us/sql/relational-databases/performance/joins?view=sql-server-ver17
  97. https://dev.mysql.com/doc/refman/8.4/en/subqueries.html
  98. https://learn.microsoft.com/en-us/sql/relational-databases/performance/subqueries?view=sql-server-ver17
  99. https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Using-Subqueries.html
  100. https://dev.mysql.com/doc/refman/8.4/en/subquery-optimization.html
  101. https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/Analytic-Functions.html
  102. https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/window-functions-in-sql/
  103. https://www.postgresql.org/docs/current/functions-window.html
  104. https://learn.microsoft.com/en-us/sql/t-sql/queries/with-common-table-expression-transact-sql?view=sql-server-ver17
  105. https://docs.snowflake.com/en/user-guide/queries-cte
  106. https://www.sqlservertutorial.net/sql-server-basics/sql-server-recursive-cte/
  107. https://www.c-sharpcorner.com/article/sql-server-cte-usage-features-and-limitations/
  108. https://spark.apache.org/docs/latest/sql-performance-tuning.html
  109. https://www.yugabyte.com/blog/how-data-sharding-works-in-a-distributed-sql-database/
  110. https://docs.oracle.com/en/database/oracle/oracle-database/21/shard/query-processing-multi-shard-queries.html
  111. https://learn.microsoft.com/en-us/azure/architecture/patterns/sharding
  112. https://dev.mysql.com/doc/refman/8.4/en/federated-storage-engine.html
  113. https://www.opengroup.org/onlinepubs/9695959099/toc.pdf
  114. https://aerospike.com/glossary/distributed-sql/
  115. https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/release/0.19.0/RELEASENOTES.0.19.0.html
  116. https://ieeexplore.ieee.org/document/10020979/
  117. https://prestodb.io/
  118. https://www.cockroachlabs.com/blog/the-new-stack-meet-cockroachdb-the-resilient-sql-database/
  119. https://dl.acm.org/doi/pdf/10.1145/3318464.3386134
  120. https://www.pingcap.com/tidb/
  121. https://db-engines.com/en/system/TiDB
  122. https://cassandra.apache.org/doc/latest/cassandra/developing/cql/cql_singlefile.html
  123. https://docs.datastax.com/en/cql-oss/3.x/cql/cqlIntro.html
  124. https://www.mongodb.com/docs/manual/reference/sql-aggregation-comparison/
  125. https://aws.amazon.com/blogs/aws/amazon-redshift-the-new-aws-data-warehouse/
  126. https://dl.acm.org/doi/10.1145/2791405.2791432
  127. https://sql-99.readthedocs.io/en/latest/chapters/12.html
  128. http://infolab.stanford.edu/~ullman/fcdb/aut07/slides/or.pdf
  129. https://docs.oracle.com/en/database/oracle/oracle-database/26/arpls/ANYDATA-TYPE.html
  130. https://www.postgresql.org/docs/current/tutorial-inheritance.html
  131. https://www.iso.org/standard/53698.html
  132. https://www.researchgate.net/publication/221323544_SQLMM_Spatial_-_The_Standard_to_Manage_Spatial_Data_in_a_Relational_Database_System
  133. http://www.refractions.net/products/postgis/history/
  134. https://users.cms.caltech.edu/~donnie/dbcourse/intro0607/lectures/Lecture3.pdf
  135. https://www.sigmod.org/publications/dblp/db/systems/qbe.html
  136. https://pages.cs.wisc.edu/~dbbook/openAccess/thirdEdition/qbe.pdf
  137. https://learn.microsoft.com/en-us/answers/questions/4922517/access-grid-queries-are-qwe
  138. https://neo4j.com/docs/cypher-manual/current/introduction/cypher-overview/
  139. https://arangodb.com/unified-query-languageaql/
  140. https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/june/the-evolution-of-linq-and-its-impact-on-the-design-of-csharp
  141. https://pages.iai.uni-bonn.de/manthey_rainer/IIS_1819/IIS18_Chapter2.pdf
  142. http://cseweb.ucsd.edu/classes/wi19/cse132B-a/slides/qbe-book.pdf
  143. https://courses.cs.duke.edu/spring03/cps216/papers/date-1983.pdf
  144. https://www.geldata.com/blog/we-can-do-better-than-sql
  145. https://www.cidrdb.org/cidr2024/papers/p48-neumann.pdf
  146. https://www.postgresql.org/docs/current/sql-keywords-appendix.html
  147. https://dev.to/sylwiavargas/cs-trivia-7-why-is-sql-shouting-at-me-5f8e
  148. http://www.bitsavers.org/magazines/Datamation/19880815.pdf
  149. https://ieeexplore.ieee.org/document/5071809
  150. https://dl.acm.org/doi/10.4018/JDM.2020100101
  151. https://ieeexplore.ieee.org/document/8659222
  152. https://docs.jboss.org/hibernate/orm/5.6/userguide/html_single/Hibernate_User_Guide.html#fetching
  153. https://use-the-index-luke.com/sql/join/nested-loops-join-n1-problem
  154. https://docs.oracle.com/en/database/oracle/oracle-database/18/shard/sharding-overview.html
  155. https://www.pingcap.com/blog/acid-at-scale-why-mysql-needs-distributed-sql-alternative/
  156. https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/july/data-points-five-ways-to-rev-up-your-sql-performance
  157. https://www.sqlshack.com/poor-database-indexing-sql-query-performance-killer-recommendations/
  158. https://learn.microsoft.com/en-us/ef/ef6/
  159. https://docs.jboss.org/hibernate/orm/5.6/userguide/html_single/Hibernate_User_Guide.html#hql-select-fetch
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.