SQL

데이터 정의 언어는 데이터베이스의 구조를 정의하고 변경하며 삭제하는 데 사용되는 SQL 명령어들의 집합이다. 이 언어를 통해 사용자는 데이터베이스 스키마를 생성하고 관리한다. 주요 명령어로는 CREATE, ALTER, DROP이 있으며, 이들은 각각 객체 생성, 구조 변경, 객체 삭제 기능을 담당한다.

가장 기본적인 명령어는 CREATE이다. CREATE TABLE 문을 사용하면 새로운 테이블을 정의할 수 있으며, 이때 컬럼의 이름, 데이터 타입, 제약 조건 등을 지정한다. 예를 들어, 기본 키나 외래 키 제약을 설정하여 데이터 무결성을 보장할 수 있다. CREATE INDEX는 검색 성능을 향상시키기 위한 인덱스를 생성하고, CREATE VIEW는 하나 이상의 테이블을 기반으로 한 가상 테이블인 뷰를 정의한다.

기존 객체의 구조를 수정할 때는 ALTER 명령어를 사용한다. ALTER TABLE 문은 테이블에 새로운 컬럼을 추가하거나, 기존 컬럼의 데이터 타입을 변경하며, 제약 조건을 추가 또는 삭제하는 작업을 수행한다. 이 명령어를 통해 데이터베이스 구조를 중단 없이 진화시킬 수 있다.

객체를 데이터베이스에서 완전히 제거하려면 DROP 명령어를 사용한다. DROP TABLE은 테이블과 그 안의 모든 데이터를 삭제하며, DROP INDEX나 DROP VIEW는 각각 인덱스와 뷰를 제거한다. 이 작업은 주의를 요하며, 일반적으로 되돌릴 수 없다. 일부 데이터베이스 시스템은 실수를 방지하기 위해 DROP TABLE IF EXISTS와 같은 조건부 삭제 구문을 지원한다.

데이터 조작 언어는 데이터베이스 내에 저장된 데이터를 직접 조작하는 데 사용되는 SQL 명령어들의 집합이다. 주로 데이터의 검색, 추가, 수정, 삭제 작업을 수행하며, 데이터베이스 사용자가 가장 빈번하게 접하는 부분이다.

핵심 명령어는 네 가지로 구성된다. SELECT 문은 하나 이상의 테이블에서 데이터를 조회한다. INSERT 문은 테이블에 새로운 행을 추가한다. UPDATE 문은 테이블 내 기존 행의 데이터를 수정한다. DELETE 문은 테이블에서 특정 행을 제거한다. 이 중 SELECT는 데이터를 변경하지 않고 읽기만 하는 반면, 나머지 세 명령어는 데이터 자체를 변경하므로 주의해서 사용해야 한다.

DML 작업은 종종 WHERE 절과 함께 사용되어 특정 조건을 만족하는 데이터만 대상으로 한다. 예를 들어, UPDATE employees SET salary = salary * 1.1 WHERE department = 'Sales';와 같은 구문은 'Sales' 부서 직원의 급여만 10% 인상한다. 조건이 생략되면 테이블의 모든 행에 영향을 미치므로, 특히 UPDATE와 DELETE 실행 시 조건을 명시하는 것이 중요하다.

다음은 주요 DML 명령어의 기본 형식을 보여주는 표이다.

이러한 DML 명령어의 실행은 일반적으로 하나의 트랜잭션으로 묶인다. 따라서 변경 사항은 COMMIT 명령어를 통해 확정되거나, ROLLBACK 명령어를 통해 실행 전 상태로 되돌릴 수 있다.

데이터 제어 언어는 데이터베이스의 보안과 권한 관리를 담당하는 SQL 명령어 집합이다. 주로 데이터베이스 관리자(DBA)가 사용하며, 사용자에게 데이터베이스 객체에 대한 접근 권한을 부여하거나 회수하는 데 중점을 둔다. 이를 통해 데이터 무결성과 보안을 유지하고, 허가되지 않은 접근으로부터 시스템을 보호한다.

DCL의 핵심 명령어는 GRANT와 REVOKE이다. GRANT 문은 특정 사용자나 역할(Role)에게 특정 권한을 부여한다. 부여할 수 있는 권한에는 객체(예: 테이블, 뷰)에 대한 SELECT, INSERT, UPDATE, DELETE, REFERENCES와 같은 객체 권한과, CREATE SESSION, CREATE TABLE과 같은 시스템 권한이 포함된다. REVOKE 문은 반대로 이미 부여된 권한을 취소한다.

권한 관리는 세분화되어 이루어진다. 예를 들어, 한 사용자에게 특정 테이블에 대해 SELECT 권한만 부여하여 데이터 조회는 허용하지만, 데이터 변경(INSERT, UPDATE)은 불가능하게 할 수 있다. 또한, WITH GRANT OPTION 절을 사용하면 권한을 받은 사용자가 다른 사용자에게 동일한 권한을 부여할 수 있는 권한까지 위임할 수 있다.

이러한 권한 제어 메커니즘은 다중 사용자 환경에서 데이터베이스의 안전한 운영을 위한 필수적인 요소이다. 일부 데이터베이스 시스템에서는 DENY와 같은 추가적인 명령어를 제공하여 명시적으로 특정 권한을 거부하는 기능도 지원한다[1].

트랜잭션 제어 언어는 데이터베이스 트랜잭션의 시작과 종료, 그리고 내부의 저장점을 관리하는 명령어들의 집합이다. 이 명령어들을 통해 여러 개의 데이터 조작 언어 작업을 논리적인 하나의 작업 단위로 묶고, 그 결과를 데이터베이스에 영구적으로 반영하거나 취소할 수 있다. 이를 통해 데이터의 무결성과 일관성을 보장한다.

주요 명령어로는 COMMIT, ROLLBACK, SAVEPOINT가 있다. COMMIT 명령은 현재 트랜잭션에서 수행한 모든 변경 사항을 데이터베이스에 영구적으로 저장하고 트랜잭션을 종료한다. ROLLBACK 명령은 트랜잭션 시작 이후 또는 특정 저장점 이후의 모든 변경 사항을 취소하고 트랜잭션을 종료한다. SAVEPOINT는 트랜잭션 내에 특정 지점을 저장점으로 설정하여, 이후에 ROLLBACK TO SAVEPOINT 명령으로 해당 저장점까지만 변경을 취소할 수 있게 한다.

이러한 명령어들은 일반적으로 데이터 조작 언어 문장들 사이에서 사용된다. 예를 들어, 여러 개의 UPDATE 문을 실행한 후 문제가 없으면 COMMIT으로 확정하고, 오류가 발생하면 ROLLBACK으로 모든 UPDATE를 원상태로 되돌릴 수 있다. 데이터 정의 언어 문장은 대부분 자동으로 커밋되는 경우가 많아 트랜잭션 제어 언어로 롤백할 수 없는 경우도 있다.

SELECT 문은 SQL에서 데이터를 검색하는 데 사용되는 가장 기본적이고 핵심적인 명령어이다. 이 문은 하나 이상의 테이블에서 사용자가 지정한 조건에 맞는 행과 열을 선택하여 결과 집합을 반환한다. 기본 구조는 SELECT 열_목록 FROM 테이블_이름이며, 여기에 다양한 절을 추가하여 검색을 세밀하게 제어할 수 있다.

검색의 정밀도를 높이기 위해 WHERE 절을 사용하여 특정 조건을 만족하는 행만 필터링할 수 있다. 예를 들어, WHERE salary > 50000은 급여가 5만을 초과하는 직원 레코드만 선택한다. 결과의 순서를 지정하려면 ORDER BY 절을 사용하며, 오름차순(ASC) 또는 내림차순(DESC) 정렬이 가능하다. 중복된 행을 제거하고 싶을 때는 SELECT 키워드 뒤에 DISTINCT를 추가한다.

SELECT 문은 단순한 데이터 조회를 넘어, 표현식과 열 별칭을 사용하여 계산된 값을 출력할 수 있다. 예를 들어, SELECT unit_price * quantity AS total_amount는 단가와 수량을 곱한 총액을 total_amount라는 새 열 이름으로 보여준다. 또한, 여러 테이블을 연결하는 조인이나 집계 함수와 함께 사용되어 복잡한 데이터 분석의 기초를 형성한다.

조인은 둘 이상의 테이블에 저장된 관련 데이터를 연결하여 하나의 결과 집합으로 만드는 SQL의 핵심 연산이다. 관계형 데이터베이스의 정규화된 데이터를 효율적으로 통합하는 데 필수적이다. 조인의 기본 원리는 두 테이블 간에 공통된 열(기본 키와 외래 키 관계가 일반적)을 기준으로 행을 결합하는 것이다.

가장 일반적인 조인 유형은 다음과 같다.

조인은 명시적 조인 구문(JOIN ... ON)을 사용하거나, WHERE 절에 조인 조건을 명시하는 암시적 조인 구문으로 작성할 수 있다. 현대적인 SQL에서는 가독성과 명확성을 위해 명시적 조인 구문을 사용하는 것이 권장된다. 조인 조건을 정확히 지정하지 않거나, 카디널리티가 높은 열을 조인하면 의도하지 않은 많은 수의 행이 생성되어 성능에 심각한 영향을 미칠 수 있다.

집계 함수는 테이블의 여러 행을 그룹화하여 하나의 결과 값을 계산하는 함수이다. 대표적인 집계 함수로는 COUNT, SUM, AVG, MAX, MIN 등이 있다. 예를 들어, SUM(price)는 특정 그룹 내 모든 price 값의 합계를 반환한다. 이러한 함수는 단독으로 사용되어 전체 테이블에 대한 통계를 낼 수도 있고, GROUP BY 절과 결합하여 특정 기준별로 그룹화된 통계를 생성하는 데 더욱 자주 사용된다.

GROUP BY 절은 지정된 하나 이상의 열을 기준으로 행을 그룹으로 묶는다. 집계 함수는 각 그룹 내의 데이터에 대해 개별적으로 적용된다. 기본 문법은 SELECT column1, AGG_FUNC(column2) FROM table GROUP BY column1; 형태를 따른다. 이때 SELECT 절에 나열된 모든 일반 열(집계 함수가 적용되지 않은 열)은 반드시 GROUP BY 절에 포함되어야 한다. 그렇지 않으면 문법 오류가 발생한다.

GROUP BY 절과 함께 HAVING 절을 사용하면, WHERE 절이 개별 행을 필터링하는 것과 달리, 집계 결과를 바탕으로 그룹 자체를 필터링할 수 있다. 예를 들어, 평균 급여가 특정 값 이상인 부서만 조회하려면 GROUP BY dept_id HAVING AVG(salary) > 50000과 같은 조건을 추가한다. WHERE 절은 그룹화 전 행을 필터링하고, HAVING 절은 그룹화 후 생성된 그룹을 필터링한다는 점이 핵심 차이점이다.

집계 함수와 GROUP BY를 효과적으로 사용하기 위해서는 데이터의 분포와 그룹화의 목적을 이해하는 것이 중요하다. 잘못 설계된 그룹화는 성능 저하를 초래하거나 의미 없는 결과를 도출할 수 있다. 또한, ROLLUP이나 CUBE와 같은 확장 구문을 사용하면 소계(Subtotal)나 총계(Grand Total)를 포함한 다차원적인 집계 결과를 생성할 수 있다.

서브쿼리는 하나의 SQL 문 내에 포함된 또 다른 SELECT 문이다. 주 쿼리의 조건이나 결과 집합을 구성하기 위해 내부적으로 실행되는 쿼리를 의미하며, 괄호로 묶어서 표현한다. 서브쿼리는 단일 값을 반환하는 스칼라 서브쿼리, 여러 행과 단일 열을 반환하는 서브쿼리, 여러 행과 여러 열을 반환하는 서브쿼리 등 그 형태에 따라 다양하게 활용된다.

서브쿼리는 주로 WHERE 절, FROM 절, SELECT 절에 위치한다. WHERE 절에서는 IN, EXISTS, ANY, ALL 등의 연산자와 함께 사용되어 조건을 필터링하는 데 쓰인다. 예를 들어, 특정 부서에 속한 직원을 찾기 위해 부서 테이블을 먼저 조회하는 방식이다. FROM 절에 사용되는 서브쿼리는 인라인 뷰라고 불리며, 하나의 임시 테이블처럼 동작하여 주 쿼리에서 조인이나 추가 조작의 대상이 된다.

서브쿼리의 성능은 데이터베이스 시스템의 옵티마이저에 의해 최적화되지만, 주의 깊게 작성하지 않으면 성능 저하를 초래할 수 있다. 특히 상관 서브쿼리는 외부 쿼리의 각 행에 대해 내부 쿼리가 반복 실행되기 때문에 데이터 양이 많을 경우 비효율적일 수 있다. 이러한 경우 조인 연산으로 재작성하는 것이 성능 향상에 도움이 되는 경우가 많다[3].

서브쿼리의 주요 유형과 사용 예는 다음과 같이 정리할 수 있다.

테이블은 관계형 데이터베이스에서 데이터를 저장하는 기본 단위이다. 행과 열로 구성되며, 각 열은 특정 데이터 타입을 가진다. 테이블은 데이터 정의 언어를 사용하여 생성, 변경, 삭제된다. 테이블의 구조는 스키마에 의해 정의되며, 기본 키, 외래 키 등의 제약 조건을 통해 데이터 무결성을 보장한다.

뷰는 하나 이상의 테이블로부터 유도된 가상 테이블이다. 실제 데이터를 저장하지 않고, 저장된 쿼리의 결과를 테이블처럼 보여준다. 뷰는 복잡한 쿼리를 단순화하거나, 특정 사용자에게 보여줄 데이터를 제한하는 데 사용된다. 보안 계층으로서의 역할도 수행한다[4].

테이블과 뷰의 주요 차이점은 다음과 같다.

뷰는 크게 단순 뷰와 복합 뷰로 나눌 수 있다. 단순 뷰는 하나의 테이블에서 파생되며, 데이터 수정이 가능한 경우가 많다. 복합 뷰는 여러 테이블을 조인하거나 집계 함수를 사용하여 생성되며, 주로 읽기 전용으로 사용된다.

인덱스는 데이터베이스 내의 테이블에 대한 검색 성능을 향상시키기 위해 사용되는 자료 구조이다. 책의 색인과 유�사하게, 특정 컬럼(열)의 값을 기반으로 데이터의 물리적 위치를 빠르게 찾을 수 있도록 하는 포인터 역할을 한다. 테이블에 인덱스를 생성하면, 해당 컬럼을 기준으로 한 정렬된 데이터 구조가 별도로 생성되고 유지 관리된다. 이 구조는 주로 B-트리나 해시 테이블과 같은 알고리즘을 기반으로 구현된다.

인덱스의 주요 유형으로는 단일 컬럼에 생성하는 단일 인덱스, 여러 컬럼을 조합하여 생성하는 복합 인덱스, 그리고 데이터의 물리적 정렬 순서와 일치하는 클러스터형 인덱스가 있다. 클러스터형 인덱스는 테이블당 보통 하나만 생성할 수 있으며, 데이터 자체를 지정된 키 값 순서로 저장하고 재구성한다. 반면, 비클러스터형 인덱스는 테이블 데이터와는 별도의 구조로 존재하며, 여러 개를 생성할 수 있다.

인덱스 설계는 신중하게 이루어져야 한다. 적절한 인덱스는 SELECT 쿼리의 속도를 획기적으로 개선하지만, 불필요하거나 과도한 인덱스는 성능에 부정적인 영향을 미친다. 인덱스가 존재하는 테이블에 데이터를 추가(INSERT), 수정(UPDATE), 삭제(DELETE)할 때마다 인덱스 구조도 함께 갱신되어야 하기 때문에, 쓰기 작업의 오버헤드가 발생한다. 또한, 인덱스를 저장하기 위한 추가적인 디스크 공간이 필요하다.

효율적인 인덱스 전략을 수립하기 위해서는 애플리케이션의 주요 쿼리 패턴, 데이터의 분포도, 그리고 조인 조건에 사용되는 컬럼 등을 분석해야 한다. 자주 검색 조건(WHERE 절)이나 정렬(ORDER BY), 조인에 사용되는 컬럼에 인덱스를 생성하는 것이 일반적이다. 데이터 변경이 빈번한 컬럼이나, 카디널리티(중복도)가 매우 낮은 컬럼(예: 성별 코드)에 대한 인덱스는 효과가 적을 수 있다. 데이터베이스 관리 시스템은 쿼리 최적화 과정에서 비용 기반 최적화를 수행하며, 가장 효율적인 인덱스를 선택하여 실행 계획을 수립한다.

저장 프로시저는 데이터베이스 서버에 저장되어 하나의 단위로 실행되는 SQL 문장들의 집합이다. 반복적으로 사용되는 복잡한 비즈니스 로직을 캡슐화하여 재사용성을 높이고, 네트워크 트래픽을 줄이며, 보안을 강화하는 데 사용된다. 저장 프로시저는 일반적으로 CREATE PROCEDURE 문으로 생성되며, EXECUTE나 CALL 명령어로 실행된다. 입력 매개변수를 받아들이고, 출력 매개변수나 결과 집합을 반환할 수 있다.

저장 함수는 프로시저와 유사하지만, 주로 단일 값을 계산하여 반환하는 데 사용된다. SELECT 문이나 표현식 내에서 직접 호출될 수 있다는 점이 프로시저와의 주요 차이점이다. 함수는 CREATE FUNCTION 문으로 정의되며, 반드시 데이터 타입을 명시하는 반환값을 가져야 한다. 함수는 다시 결정적 함수와 비결정적 함수로 구분될 수 있다[6].

이들 객체를 사용하면 애플리케이션 코드에서 직접 SQL을 작성하는 대신 데이터베이스 서버 측에 로직을 위임할 수 있다. 이는 코드 모듈화를 촉진하고, 유지보수성을 향상시키며, 데이터 접근 제어를 중앙에서 관리할 수 있게 한다. 다만, 과도한 사용은 데이터베이스 서버의 부하를 증가시키고 비즈니스 로직의 이식성을 낮출 수 있다는 점에 유의해야 한다.

실행 계획은 데이터베이스 관리 시스템이 사용자가 제출한 SQL 쿼리를 처리하기 위해 선택한 내부 작업 절차의 상세한 로드맵이다. 쿼리 옵티마이저가 여러 가능한 실행 경로 중 예상 비용을 계산하여 최적의 경로를 선택한 결과를 보여준다. 이 계획을 분석함으로써 개발자나 데이터베이스 관리자는 쿼리가 어떻게 실행될지 이해하고, 병목 현상이나 비효율적인 연산을 식별하여 성능을 개선할 수 있다.

대부분의 현대 DBMS는 EXPLAIN 또는 EXPLAIN ANALYZE와 같은 명령어를 제공하여 실행 계획을 텍스트나 그래픽 형태로 출력한다. 실행 계획은 일반적으로 트리 구조로 표현되며, 각 노드는 테이블 스캔, 조인, 정렬, 집계 등의 단일 연산을 나타낸다. 각 노드에는 해당 연산에 대한 예상 비용(예: 시작 비용, 총 비용), 예상 반환 행 수, 사용된 접근 방법(예: 인덱스 스캔, 전체 테이블 스캔) 등의 정보가 포함된다.

분석 시 주목해야 할 주요 항목은 다음과 같다.

실행 계획 분석의 핵심은 고비용 노드를 찾고, 그 원인을 파악하는 것이다. 예를 들어, 예상보다 많은 행을 처리하는 Seq Scan이 발생한다면 적절한 인덱스가 부족할 수 있다. 불필요한 Sort 연산이 있다면 인덱스를 활용해 정렬 단계를 생략할 수 있다. 또한, 옵티마이저의 예상 행 수와 실제 행 수가 크게 차이 나면 테이블 통계 정보가 오래되어 잘못된 계획을 수립했을 가능성이 있다. 이러한 분석을 바탕으로 SQL 쿼리 튜닝이나 인덱스 설계를 재검토하게 된다.

인덱스 설계는 데이터베이스 성능에 직접적인 영향을 미치는 핵심 요소이다. 효과적인 인덱스 설계 전략은 빠른 데이터 검색과 효율적인 쿼리 처리를 보장하지만, 부적절한 설계는 오히려 입출력 부하를 증가시키고 저장 공간을 낭비할 수 있다. 설계 시에는 선택도, 클러스터링 팩터, 카디널리티와 같은 개념을 고려하여 인덱스의 효용성을 판단해야 한다.

인덱스 설계의 기본 원칙은 WHERE 절이나 JOIN 조건에 자주 사용되는 컬럼, 그리고 ORDER BY나 GROUP BY 절에 사용되는 컬럼에 우선적으로 인덱스를 생성하는 것이다. 특히, 기본 키는 대부분의 시스템에서 자동으로 클러스터형 인덱스가 생성되며, 외래 키 역시 조인 성능 향상을 위해 인덱싱하는 것이 일반적이다. 복합 컬럼 인덱스를 설계할 때는 컬럼의 순서가 매우 중요하다. 가장 선택도가 높은(고유한 값이 많은) 컬럼을 선두에 배치하고, 범위 검색에 사용되는 컬럼은 뒤쪽에 배치하는 것이 효율적이다.

마지막으로, 인덱스 설계는 정적이지 않다. 애플리케이션의 쿼리 패턴이 변화함에 따라 주기적으로 인덱스 사용 현황을 모니터링하고 재평가해야 한다. 사용되지 않는 인덱스는 제거하고, 새로운 쿼리 패턴에 맞춰 인덱스를 추가하거나 기존 인덱스를 조정하는 작업이 지속적으로 필요하다. 데이터베이스 시스템이 제공하는 실행 계획 분석 도구를 활용하여 인덱스가 예상대로 효율적으로 사용되고 있는지 확인하는 것이 좋다.

쿼리 튜닝은 데이터베이스 시스템의 성능을 향상시키기 위해 SQL 문의 실행 효율성을 분석하고 개선하는 과정이다. 주된 목표는 동일한 결과를 반환하면서도 더 적은 시스템 자원(CPU, I/O, 메모리)을 사용하고 더 빠르게 실행되는 쿼리를 작성하는 것이다. 튜닝은 주로 비효율적인 인덱스 사용, 불필요한 데이터 접근, 최적화되지 않은 조인 방식 등에서 발생하는 병목 현상을 해결하는 데 초점을 맞춘다.

가장 기본적이고 효과적인 튜닝 기법은 적절한 인덱스를 활용하는 것이다. 자주 사용되는 검색 조건(WHERE 절)이나 조인 조건, 정렬(ORDER BY) 및 그룹화(GROUP BY)에 사용되는 컬럼에 인덱스를 생성하면 데이터 접근 속도가 크게 향상된다. 특히, 선택도가 높은(고유한 값이 많은) 컬럼에 인덱스를 생성하는 것이 유리하다. 반면, 너무 많은 인덱스는 데이터 갱신(INSERT, UPDATE, DELETE) 시 성능 저하를 초래할 수 있으므로 신중하게 설계해야 한다. 또한, 실행 계획을 분석하여 인덱스가 실제로 사용되고 있는지 확인하는 것이 중요하다.

쿼리 자체의 작성 방식을 최적화하는 것도 필수적이다. 불필요한 컬럼을 SELECT * 대신 명시적으로 나열하거나, 비효율적인 서브쿼리를 조인 연산으로 재작성할 수 있다. 집계 함수를 사용할 때는 가능한 한 애플리케이션 단이 아닌 데이터베이스 내에서 처리하도록 한다. 데이터 양이 많을 경우, 한 번에 모든 데이터를 가져오는 대신 페이징 처리를 적용하는 것도 효과적이다. 때로는 복잡한 단일 쿼리를 여러 개의 간단한 쿼리로 분리하거나, 반대로 여러 번 실행되는 쿼리를 하나로 통합하는 전략도 성능에 도움이 된다.

마지막으로, 데이터베이스의 옵티마이저가 최적의 경로를 선택할 수 있도록 돕는 것이 중요하다. 이를 위해 테이블과 인덱스에 대한 통계 정보가 정기적으로 갱신되어야 한다. 또한, 데이터베이스별로 제공하는 힌트(Hint) 구문을 사용하여 특정 인덱스 사용이나 조인 방식을 옵티마이저에 제안할 수 있지만, 이는 데이터 분포가 변경되면 오히려 역효과를 낼 수 있으므로 신중하게 적용해야 한다.

Oracle, MySQL, PostgreSQL은 각각 독특한 역사와 설계 철학을 바탕으로 발전했으며, 이는 SQL 구현과 확장 기능에서 뚜렷한 차이로 나타난다.

Oracle은 기업용 RDBMS 시장에서 오랜 기간 선도적 위치를 차지해왔다. 강력한 트랜잭션 처리와 데이터 일관성을 보장하는 기능에 중점을 두며, PL/SQL이라는 강력한 절차적 언어 확장을 제공한다. 고급 분석 함수, 윈도우 함수, 계층형 쿼리(CONNECT BY) 등 풍부한 기능을 자랑하며, 대용량 데이터베이스 환경에 최적화되어 있다. 라이선스 비용이 높은 상용 소프트웨어라는 점이 특징이다.

MySQL은 초기에는 속도와 단순함에 중점을 둔 경량 RDBMS로 시작해, Sun Microsystems와 이후 Oracle에 인수되면서 기능이 크게 확장되었다. 가장 널리 사용되는 오픈 소스 데이터베이스 중 하나로, LAMP 스택의 핵심 구성 요소이다. 기본 스토리지 엔진으로 MyISAM과 InnoDB를 제공하며, 5.7 버전 이후부터는 JSON 데이터 타입 지원, 윈도우 함수 등 현대적인 SQL 기능을 지속적으로 추가하고 있다. PostgreSQL에 비해 전통적으로 SQL 표준 준수보다는 실용성과 성능을 우선시하는 경향이 있었다.

PostgreSQL은 객체-관계형 데이터베이스 관리 시스템(ORDBMS)으로 분류되며, 엄격한 SQL 표준 준수와 확장성에 철학을 둔다. 다른 데이터베이스에서는 찾기 어려운 고급 데이터 타입(배열, hstore, JSONB, 기하학적 타입 등), 사용자 정의 타입, 연산자, 함수 생성 기능을 기본적으로 지원한다. 또한 MVCC 구현 방식이 매우 정교하며, 복잡한 쿼리와 분석 작업에 강점을 보인다. 모든 기능이 포함된 완전한 오픈 소스 소프트웨어라는 점이 큰 장점이다.

Microsoft SQL Server는 마이크로소프트가 개발한 관계형 데이터베이스 관리 시스템(RDBMS)이다. 주로 윈도우 서버 환경에서 운영되며, .NET 프레임워크와의 긴밀한 통합이 특징이다. Transact-SQL(T-SQL)이라는 자체 SQL 방언을 사용하며, 이는 표준 SQL에 프로시저적 확장 기능을 추가한 것이다. 기업용 애플리케이션, 비즈니스 인텔리전스(BI), 데이터 웨어하우징 분야에서 널리 사용된다.

주요 구성 요소로는 데이터베이스 엔진(SQL Server 데이터베이스 엔진) 외에도 SQL Server Reporting Services(SSRS), SQL Server Integration Services(SSIS), SQL Server Analysis Services(SSAS) 등이 포함되어 포괄적인 데이터 플랫폼을 제공한다. 최근 버전에서는 Linux 및 도커 컨테이너 지원, Azure 클라우드 서비스와의 하이브리드 기능 강화 등 개방형 플랫폼으로의 진화를 보여준다.

T-SQL은 다른 RDBMS와 구별되는 여러 기능을 제공한다. 저장 프로시저, 사용자 정의 함수, 트리거 작성에 강력한 절차적 언어 요소를 포함한다. 또한 TOP 절, OUTPUT 절, 공통 테이블 표현식(CTE) 및 윈도우 함수에 대한 풍부한 지원을 한다. 버전별로 지원하는 기능에 차이가 있어 주의가 필요하다.

관련 문서: Microsoft Docs - SQL Server