WebMaster

그룹 코드와 상세 코드 분리공통 코드를 두 개의 테이블로 분리한다. 그룹을 관리하는 테이블과 상세 코드를 관리하는 테이블이다.DROP TABLE IF EXISTS common_code;DROP TABLE IF EXISTS common_code_detail;DROP TABLE IF EXISTS common_code_group;-- 그룹 코드 테이블CREATE TABLE common_code_group ( group_code VARCHAR(50) PRIMARY KEY, group_name VARCHAR(100) NOT NULL, description VARCHAR(500), use_yn CHAR(1) NOT NULL DEFAULT 'Y', created_at DATETIME NOT NULL DEFAULT C..

공통 코드의 단순 설계공통 코드 테이블에 필요한 최소한의 정보는 무엇일까? 코드값과 표시 이름이다.DROP TABLE IF EXISTS common_code;CREATE TABLE common_code ( code VARCHAR(50) PRIMARY KEY, name VARCHAR(100) NOT NULL);INSERT INTO common_code (code, name) VALUES('ORDER', '주문접수'),('PAID', '결제완료'),('SHIPPING', '배송중'),('DELIVERED', '배송완료'),('CANCEL','주문취소');SELECT * FROM common_code;"code"를 PK로 사용한다.Join 해서 결과 보기select o.order_id, o.order_..

공통 코드가 필요한 이유?데이터베이스를 설계하다 보면 비슷한 종류의 데이터가 여러 테이블에 걸쳐 반복되는 상황을 자주 만난다. 예를 들어 주문 상태, 회원 등급, 결제 방법 같은 것들이다. 이런 데이터를 어떻게 관리해야 할까? 먼저 문제 상황부터 살펴보자. 문제 상황 - 하드코딩된 상태값쇼핑몰을 운영한다고 가정하자. 주문 테이블에는 주문 상태가 필요하다. 가장 단순한 방법은 상태값을 문자열로 직접 저장하는 것이다.DROP TABLE IF EXISTS orders;CREATE TABLE orders ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, order_status VARCHAR(20) NOT NULL, total_amo..

회원 로그인 처리상황: 사용자가 ID로 "sejong"을 입력하고 로그인을 시도한다. 시스템은 이 ID에 해당하는 회원 정보를 데이터베이스에서 조회하여 비밀번호를 검증해야 한다.EXPLAINSELECT member_id, login_id, password, -- 애플리케이션에서 비밀번호 검증을 위해 사용될 암호화된 비밀번호 member_nameFROM memberWHERE login_id = 'sejong';table: member 테이블을 사용했다.type: "const"."login_id" 컬럼은 "UNIQUE" 키이므로, MySQL은 이 쿼리를 최적화하는 단계에서 값을 상수("sejong")로 취급하고 단 하나의 행만 읽으면 된다는 것을 안다.성능이 매우 우수함을 의미한다.key: "uq_lo..

DDL 만들기Member 테이블CREATE TABLE member ( member_id BIGINT NOT NULL AUTO_INCREMENT, -- 회원 ID (PK) login_id VARCHAR(50) NOT NULL, -- 로그인 ID password VARCHAR(255) NOT NULL, -- 비밀번호 (암호화) member_name VARCHAR(50) NOT NULL, -- 이름 email VARCHAR(100) NOT NULL, -- 이메일 addr VARCHAR(255) NULL, -- 주소 created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP..

테이블 정의서기본값을 비고에 포함했다. 기본값은 별도의 항목으로 설명하는 것이 좋다."NULL"을 제약(제약 조건)에 포함했다. "NULL"은 별도의 항목으로 설명하는 것이 좋다.지면상 "NOT NULL"은 표현하지 않겠다. (여기서 기본은 "NOT NULL"로 보면 된다.)"AUTO_INCREMENT" 기본값은 생략했다."created_at", "updated_at"의 기본값은 생략했다."Unique" -> "UQ"한글명을 영문명으로 변환할 때 앞서 준비한 용어 사전을 사용하자.memberNo컬럼 한글명 컬럼 영문명 데이터 타입 제약 조건 비고1회원 IDmember_idBIGINTPK회원의 고유 식별자(대리키)2로그인 IDlogin_idVARCHAR(50)UQ회원이 로그인 시 사용하는 ID3비밀번호p..

역정규화 - 중복 컬럼 추가문제 상황주문 내역 조회는 우리 쇼핑몰에서 가장 빈번하게 일어나는 핵심 기능 중 하나다. 사용자는 "마이페이지"에서 자신의 주문 내역을 볼 때, 각 주문에 어떤 상품들이 포함되어 있는지 상품명과 함께 확인하고 싶어 한다. 현재의 정규화된 모델에서 이 기능을 구현하려면, order_item 테이블과 product 테이블을 항상 "JOIN"해야만 상품명(product_name)을 가져올 수 있다.SELECT oi.order_id, p.product_name, -- 상품명을 위해 반드시 product 테이블을 JOIN 해야 한다. oi.order_price, oi.order_quantityFROM order_item oi JOIN product p ON oi.p..

인덱스는 데이터베이스 테이블의 특정 컬럼(들)의 데이터를 빠르게 찾을 수 있도록 도와주는 일종의 "찾아보기"나 "목차"와 같다. 인덱스가 없으면, 데이터베이스는 원하는 데이터를 찾기 위해 테이블의 모든 행을 처음부터 끝까지 스캔해야 한다. 이를 풀 테이블 스캔(Full Table Scan)이라고 한다. 데이터가 수백만, 수천만 건이 되면 이는 재앙과도 같은 성능 저하를 일으킨다. "우리 쇼핑몰의 어떤 기능이 인덱스를 필요로 할까?" 이 질문에 답하기 위해, 우리 쇼핑몰에서 매우 자주 발생할 것으로 예상되는 핵심적인 조회 시나리오들을 분석하고, 그에 맞는 인덱스를 전략적으로 추가해 보자. MySQL 인덱스 자동 생성MySQL에서는 Primary Key(PK)와 Unique Key(UK), Foreign K..

논리적 모델링 확인 이 논리적 모델을 우리가 사용하기로 한 MySQL이라는 특정 데이터베이스에 맞게 변환하고, 성능과 효율성, 그리고 현실적인 제약 조건들을 고려하여 최적화하는 물리적 모델링을 진행할 차례다. 물리적 모델링물리적 모델링은 각 테이블별로 어떤 데이터 타입을 선택하고, 어떤 제약조건과 인덱스를 추가해야 할지 신중하게 결정하며 "CREATE TABLE" 구문을 완성해 나간다. 물리적 모델링의 결과는 크게 테이블 정의서와 실제 테이블을 만들 수 있는 스크립트인 DDL이 나와야 한다. 물리적 모델링의 핵심 목표 중 하나는 바로 성능이다. 논리적으로 아무리 완벽한 모델이라도, 실제 서비스에서 쿼리가 느리다면 아무 소용이 없다. 이번 시간에는 조회 성능을 극대화하기 위해 의도적으로 정규화 원칙을 위..

물리적 모델링의 최종 산출물 중 하나는 바로 테이블 정의서(Table Definition Document)다. 테이블 정의서는 데이터베이스의 각 테이블과 컬럼이 무엇을 의미하고, 어떤 규칙을 가지고 있는지 상세하게 설명하는 "설계 명세서"와 같다. 테이블 정의서, 왜 필요한가?문제 상황: 당신은 새로운 프로젝트에 투입된 개발자다. 데이터베이스 스키마를 파악하기 위해 DDL(CREATE TABLE ...) 코드를 열어보았다.CREATE TABLE order_item ( oi_id BIGINT NOT NULL AUTO_INCREMENT, o_id BIGINT NOT NULL, p_id BIGINT NOT NULL, price INT NOT NULL, qty INT NOT NULL,..