SQL

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^[21] and Mimer SQL^[22] 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,^[23] which says that unquoted names should be folded to upper case.^[24] 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,^[25][26] and lacks a TIME type)^[27] and MS SQL Server (before the 2008 version). As a result, SQL code can rarely be ported between database systems without modifications.

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.^[28]: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.

SQLは1986年にANSIによってSQL-86 ^{[ 29 ]}として、また1987年にISOによって標準として採用されました。 ^{[ 12 ]}これはISO/IEC JTC 1、情報技術、サブコミッティSC 32、データ管理と交換によって維持されています。

1996年までは、米国国立標準技術研究所（NIST）のデータ管理標準プログラムがSQL DBMSのSQL標準への準拠を認証していました。現在では、ベンダーが自社製品の準拠を自己認証しています。^{[ 30 ]}

元の標準では、「SQL」の公式の発音は頭字語/ ˌ ɛ s ˌ k juː ˈ ɛ l / ("ess cue el") であると宣言されていました。[ ^{10 ]それ}にもかかわらず、多くの英語圏のデータベース専門家（ドナルド・チェンバリン自身^{[ 31 ]}を含む）は、言語のリリース前の開発名「SEQUEL」を反映して、頭字語のような発音/ ˈ s iː k w əl / ("sequel")を使用しています。 ^{[ 32 ] [ 14 ] [ 16 ] [ 31 ] SQL 標準は、}数多くの改訂を経てきました。

規格は一般的に、ISO/IEC 9075-n:yyyy Part n: title というパターンで表記されます。または、略してISO/IEC 9075と表記されます。関係者は、ISO ^{[ 37 ]} IEC または ANSIから規格文書を購入できます。古い草案は無料で入手できます。^{[ 38 ] [ 39 ]}

ISO/IEC 9075は、ISO/IEC 13249: SQL マルチメディアおよびアプリケーション パッケージといくつかの技術レポートによって補完されています。

SQLは、その理論的基盤である関係モデルとそのタプル計算からいくつかの点で逸脱している。関係モデルでは、テーブルはタプルの集合であるが、SQLでは、テーブルとクエリ結果は行のリストであり、同じ行が複数回出現する可能性があり、クエリでは行の順序を使用できる（例えば、LIMIT句内）。批判者たちは、SQLは厳密に元の基盤に戻る言語に置き換えるべきだと主張している。例えば、ヒュー・ダーウェンとCJ・デイトによる『第三マニフェスト』（2006年、ISBN 1000）を参照。 0-321-39942-0)

初期の仕様では、主キーなどの主要な機能はサポートされていませんでした。結果セットに名前を付けることはできず、サブクエリも定義されていませんでした。これらは1992年に追加されました。^{[ 13 ]}

和型がないことは、SQLのユーザー定義型を完全に利用する上での障害となっていると指摘されている。例えば、JSONのサポートは2016年に新しい標準によって追加される必要があった。^{[ 45 ]}

Nullの概念は議論の対象となっている。Null マーカーは値の欠如を示し、整数列の 0 やテキスト列の空文字列とは異なる。Null の概念はSQL の 3 値論理を強制するものであり、これは一般的な3 値論理の具体的な実装である。^{[ 13 ]}

もう1つのよくある批判は、重複行を許容するため、 Pythonなどの言語との統合が困難になるという点です。Pythonのデータ型では、解析の面でもモジュール性の欠如の面でも、データを正確に表現することが難しい場合があります^{[ 13 ]}。これは通常、テーブル内の行を一意に識別する1つ以上の列を持つ主キーまたは一意制約を宣言することで回避されます。

オブジェクトリレーショナルインピーダンスミスマッチと同様の意味で、宣言型SQL言語と、SQLが通常埋め込まれている手続き型言語との間にミスマッチが発生する。^{[ 46 ]}

• 文字タイプ
  • キャラクター （CHAR）
  • 文字が変化する（VARCHAR）
  • 文字の大きなオブジェクト（CLOB）
• 国民性のタイプ
  • 国民性（NCHAR）
  • 国民性は様々である（NCHAR VARYING）
  • 国民的特性を示す大型オブジェクト（NCLOB）
• バイナリ型
  • バイナリ（BINARY）
  • バイナリ変動（VARBINARY）
  • バイナリラージオブジェクト（BLOB）
• 数値型
  • 正確な数値型（NUMERIC、、、、）DECIMALSMALLINTINTEGERBIGINT
  • 近似数値型（FLOAT、、）REALDOUBLE PRECISION
  • 10進浮動小数点型（DECFLOAT）
• 日時型（DATE、、TIME）TIMESTAMP
• 区間タイプ（INTERVAL）
• ブール値
• XML（SQL/XMLを参照）^{[ 47 ]}
• JSON