DDL - 데이터 정의어

DDL : DB/테이블 을 생성하거나, 수정, 삭제 등 데이터베이스의 구조를 정의하는 문법

DB 생성/삭제/선택

DROP DATABASE test_db;
-- test_db 라는 이름의 데이터베이스를 삭제하지만, 만약 db가 존재하지 않는다면 에러가 발생한다.

DROP DATABASE IF EXISTS test_db
--IF EXISTS 조건을 통해 test_db가 존재하는 경우에만 삭제하기 때문에 위에서 말한 에러가 발생하지 않는다.

CREATE DATABASE test_db;
-- test_db 라는 이름의 데이터베이스를 생성한다.

USE test_db;
-- 앞에서 만든 test_db 를 사용하도록 설정한다.
-- 이 쿼리를 실행하지 않고 데이터를 조작하게 되면 어떤 DB를 사용해야 할지 모르므로 오류가 발생한다.

Table 생성/수정/삭제

CREATE TABLE test_table (
	table_id INT AUTO_INCREMENT PRIMARY KEY,
	name VARCHAR(20) NOT NULL,
	email VARCHAR(128) NULL,
	created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP()
);
-- test_table 이라는 이름의 테이블을 생성한다.
-- table_id 라는 이름으로 PK를 만들고, AUTO_INCREMNT 를 설정해 자동으로 값이 증가하게 하였다.
-- 만약 현재 마지막 데이터의 id가 2라면, 그 다음에 추가되는 데이터의 id는 자동으로 3이 된다.

ALTER TABLE test_table ADD COLUMN age INT NOT NULL DEFAULT 0;
-- ALTER : 테이블을 수정하는 문법이다.
-- ADD COLUMN : 새로운 컬럼을 추가한다.

ALTER TABLE test_table MODIFY COLUMN name VARCHAR(30) NOT NULL;
-- MODIFY COLUMN : 기존에 존재하는 컬럼을 수정한다. 
-- 수정 시 수정할 부분 뿐만 아니라 컬럼명, 타입, 제약조건까지 다 적어줘야 한다.

ALTER TABLE test_table CHANGE COLUMN email user_email VARCHAR(128) NOT NULL;
-- CHANGE COLUMN : MODIFY의 기능과 더불어 기존 컬럼의 이름까지 변경 할 수 있다.

ALTER TABLE test_table DROP COLUMN age;
-- 테이블에 존재하는 특정 컬럼을 아예 삭제한다.

DROP TABLE test_table;
-- test_table 이라는 이름의 테이블을 삭제한다.
-- 데이터베이스와 동일하게 IF EXISTS 조건을 넣을 수 있다.

TRUNCATE TABLE test_table;
-- test_table 이라는 이름의 테이블은 그대로 두고, 테이블 안의 데이터들만 삭제한다.
-- DELETE FROM test_table 과 동작은 같지만, 아래와 같은 차이가 있다.
-- DELETE FROM test_table은 한 행씩 지우면서 기록을 남긴다.
-- 반면 TRUNCATE는 그냥 테이블을 다 비우기만 하면 되서 조금 더 빠르고 간단하다.
-- TRUNCATE 는 PK의 자동 증가 값도 초기화 한다.
-- 만약 현재 가장 큰 id가 100 이라고 해도 TRUNCATE를 하게 된다면 0으로 초기화 된다.
-- 보통은 테이블은 남기고 내부 데이터는 전부 지우고 싶다면 TRUNCATE가 유용하다.
-- 만약 특정 조건을 가진 행만 삭제한다면 DELETE를 사용해야 한다.

VARCHAR vs CHAR
- VARCHAR
  - 저장할 최대 바이트 크기를 지정해 해당 크기까지 문자열을 저장할 수 있다.
  - 데이터 + 데이터의 길이까지 저장하기 때문에 공간을 조금 더 쓸 수도 있지만, CHAR 처럼 무조건 최대 크기를 쓰는 것이 아니기 때문에 메모리를 더 효율적으로 사용할 수 있다.
  - VARCHAR는 데이터 크기가 자주 변경되면 데이터 단편화 등이 발생해 성능이 조금 저하될 수 있다.
- CHAR
  - 처음에 지정한 최대 크기까지 문자열을 저장할 수 있지만, 만약 최대크기보다 작은 데이터라면 남은 공간을 공백으로 채운다.
  - 데이터의 크기가 확실하게 고정된 경우 (주민등록번호, 국가 코드 등) VARCHAR 보다 나은 선택일 수도 있다.
  - 데이터의 크기가 모두 동일하므로 만약 저장되는 데이터의 크기가 더 작을수록 공간 낭비가 심해진다.
- 결론
  - 일반적인 경우에는 VARCHAR 를 대부분 사용하는 경우가 많다.
    - 이유 : 만약 데이터의 크기가 더 커져야 하는 경우에도 공간 낭비 없이 사용할 수 있다.
  - CHAR 같은 경우에는 위에서 말한 것처럼 정말 길이가 변할 가능성이 없는 데이터를 저장할때 는 사용할 수도 있다.
DATETIME vs TIMESTAMP
- DATETIME
  - 타임존과 관련된 처리를 하지 않고 값 그대로 저장하고 그대로 보여준다.
  - 1000 ~ 9999년 까지도 저장할 수 있다.
  - 저장공간은 5바이트 + 알파 로 TIMESTAMP 보다는 살짝 더 크다.
  - 데이터 생성/업데이트 시 자동으로 시간을 기록해주는 기능도 최근에는 지원하고 있다.
- TIMESTAMP
  - 저장 시 UTC 기준으로 시간을 변환해 저장하고, 조회 시 사용자의 타임존에 맞춰 변환해서 보여준다.
  - 1970 ~ 2038 년 정도까지만 저장할 수 있다.
  - 4바이트 + 알파 정도의 저장공간을 차지한다.
  - 데이터 생성/업데이트 시 자동으로 시간을 기록해주는 기능을 지원한다.
- 결론
  - TIMESTAMP 는 2038년 까지만 기록되기 때문에 현재 기준으로는 사용하기 힘들 수 있다.
  - 또한 TIMESTAMP 만 지원하던 기능도 DATETIME 이 지원하게 되었으므로 요즘은DATETIME 을 사용하는게 좋다.
  - 타임존과 관련된 부분도 DATETIME은 신경쓰지 않기 때문에 사용자가 맘놓고 관리할수 있다.
제약

CREATE TABLE users (
	user_id INT AUTO_INCREMENT PRIMARY KEY,
	name VARCHAR(10) NOT NULL,
	email VARCHAR(128) NOT NULL UNIQUE
);
CREATE TABLE orders (
	order_id INT AUTO_INCREMENT PRIMARY KEY,
	order_date DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP(),
	user_id INT NOT NULL,
	CONSTRAINT fk_orders_users FOREIGN KEY user_id REFERENCES users(user_id)
);

-- 이런식으로 NOT NULL, NULL, UNIQUE, FOREIGN KEY 등 다양한 제약을 설정할 수 있다.

-- NOT NULL / NULL : NULL을 허용하거나 허용하지 않을 수 있다.
-- NOT NULL 이라면 기본값이 없을 때 데이터 삽입 시 해당 컬럼의 값을 포함하지 않는다면 오류가 날 수 있다.

-- UNIQUE : 해당 컬럼을 테이블의 유일한 값으로 관리되도록 할 수 있다.
-- UNIQUE 이 정의된 컬럼은 해당 컬럼이 존재하는 테이블 안에서는 중복될 수 없다.
-- 만약 중복된다면 오류가 발생하며, 이런 제약은 데이터 무결성을 지킬 수 있다.
-- CONSTRAINT uc_abc UNIQUE (first, second) 처럼 여러 컬럼의 조합으로도 유일값을 만들 수 있다.
-- 이 경우 삽입하려는 데이터의 first 컬럼 값이 존재하고, second 컬럼 값도 존재한다면 오류가 발생한다.
-- 만약 first 컬럼 값은 존재하지만 second 컬럼 값은 존재하지 않는다면 해당 데이터는 정상적으로 삽입된다.
-- 반대도 마찬가지며, 한마디로 first + second 조합으로 비교해 완전히 똑같다면 유일한 것으로 판단한다.

-- FOREIGN KEY : 두 테이블의 관계를 이어주는 외래키를 설정한다.
-- 외래키가 존재하는 테이블은 보통 자식 테이블이라고 하며, 나머지를 부모 테이블이라고 한다.
-- 자식 테이블에 부모 테이블의 PK를 저장하므로써 두 테이블이 논리적으로 연관되어 있도록 만든다.
-- 만약 부모 테이블에 존재하지 않는 id를 FK에 저장한다면 오류가 발생한다.
-- FK는 JOIN에서 가장 의미있게 사용될 수 있는데, 자식과 부모를 JOIN 으로 붙여서 더 많은 정보를 조회 할 수 있다.