DB_진짜_진짜_최종

로그(이력, 감사, 활동 등) 데이터 저장 위치

• 로그(이력, 감사, 활동 등) 데이터 저장 위치는 시스템 요구사항, 서비스 보안, 확장성·분석 목적에 따라 결정

1. DB에 로그 저장

• 주로 저장하는 경우:
  • 중요 비즈니스 이벤트(사용자 행동, 데이터 변경 내역, 관리자 작업 등)
  • 권한/보안/감사 추적이 필요한 이력(예: 접속 기록, 변경 로그, 개인정보 접근 이력 등)
  • 통합 통계/관리, 복잡한 쿼리 분석 및 대시보드용 집계가 필요한 경우
  • 공공기관, SaaS, 엔터프라이즈 환경(법적 기록 보존, 추후 감사)을 요구하는 프로젝트
• 장점:
  • SQL로 바로 검색·집계·통계 등 복잡한 쿼리 가능
  • 사용자 기준/시간 기준 등 다차원 검색 용이
  • 외부 연동, 통계, 시스템 변경 이력 등 활용도가 높음
  • 데이터 무결성/보안(권한/암호화) 관리에 강점
• 단점:
  • 많은 로그가 쌓일 경우 DB 성능·용량에 부담
  • 실시간 처리/대용량 로그에는 비적합할 수 있음

2. 백엔드(파일, 로거, 로그 서버 등)에 저장

• 주로 저장하는 경우:
  • 어플리케이션 동작(에러, 접근, 성능 로그 등)
  • 파일 시스템(예: 로그 파일, syslog, cloud log, ELK stack)
  • 실시간 모니터링·알림, 전체 서비스 장애·디버깅 용도
  • DB 부담을 줄여야 하거나, 단순 기록만을 위한 로그
• 장점:
  • 대용량 처리/저장에 효율적 (파일 분할, 로그 서버, 클러스터 활용)
  • 빠른 쓰기/비용 절감, 별도 로그 분석 시스템 연계 쉽고,
  • DB 성능에 미치는 영향 적음
• 단점:
  • 파일 기반 검색·집계가 어렵고, SQL 검색 불가
  • 실시간 응답·비즈니스 기반 통합 조회/집계에 제한
  • 데이터 보존·변경 이력 감사 기능 부족

실전 권장 기준

• “백엔드 로그” + “DB 이력”을 조합하는 것이 가장 많습니다.
  • 필수 감사·보안·권한 관련 이벤트, 사용자의 중요한 액션/변동 데이터 → DB 테이블에 저장
  • 단순 어플리케이션 로그(에러, 디버깅, 트래픽/모니터링) → 파일, 로그 서버, 외부 시스템에 저장
• 보안/법적 이슈, 추후 감사·통계 필요하면 반드시 DB 저장!
• 백엔드 로그만 쓰면 실시간 처리에는 좋아도,
  이력/통계/법적 감사/개별 검색에 매우 불리합니다.

정리

• 중요한 기록·분석·추적이 필요한 로그는 DB 테이블 저장,
• 단순 어플리케이션 동작 기록이면 백엔드 로그로 충분
• 대부분의 실무 서비스는 두 방식을 병행함
• 필요 목적·데이터 중요도에 맞게 선택하기

만들면서 배운 내용 정리

• 로그 테이블에서는 ON DELETE SET NULL이 실무적으로 가장 일반적이고, 권장되는 방식
  • 로그 기록을 보존해야 하는 경우 → FK 컬럼(NULL 허용) + ON DELETE SET NULL
    • FK 컬럼이 NULL 가능이어야 하며, 부모가 삭제되면 참조 FK만 NULL로 바꿈
  • 실무적/법적 기록 보존 목적에 딱 맞는 선택
• ON DELETE CASCADE
  • FK 컬럼이 NOT NULL이어야 함
    • NOT NULL + ON DELETE SET NULL → 오류
    • NULL + ON DELETE SET NULL → 정상
  • 부모 테이블이 삭제될 때 반드시 자식 레코드도 함께 삭제해야 한다면 사용
    • 로그가 같이 삭제됨, 데이터 무결성 최우선 시 적용

• 로그성 테이블의 컬럼 → NULL 허용 권장
  • 로그/이력 테이블(*_log)의 changed_by, updated_by와 같은 컬럼은
    관리자(또는 사용자) 계정이 삭제되어도 기록 자체를 보존하는 것이 보통입니다.
  • 계정이 삭제되면 해당 컬럼만 NULL로 남기고,
    로그 레코드 자체는 유지되는 것이 일반적인 감사(audit) 정책입니다.
  • 장점
    • 로그 데이터 삭제 위험이 없음
    • 나중에 계정 테이블이 정리돼도 변경 이력이나 행동 이력을 계속 참조할 수 있음
    • MySQL ON DELETE SET NULL 로 연계되므로 추가 관리나 예외처리 부담이 적음
• NOT NULL + CASCADE/RESTRICT → 데이터 무결성 최우선 상황에만
  • 만약 로그를 포함한 모든 데이터가 삭제되어야 하는 비즈니스 정책 (예: 개인정보 완전 삭제)이면 CASCADE를 선택하고, 컬럼을 NOT NULL로 유지할 수 있음.
• 하지만 대다수의 서비스에서는 기록 보존이 더 중요하며, 삭제 시 NULL 처리로 남기고, 삭제 행위 추후 감사가 가능해야 함
• 결론
  • 대부분의 로그/이력 관리 목적 시스템에서는 SET NULL이 포함된 NULL 허용 컬럼이 압도적으로 많이 쓰임
  • DB 및 보안 정책, 추후 감사, 보존 목적 등 실용/법적 요구사항에도 적합함
  • 예외적으로, 데이터 완전 삭제(파기)가 중요하다면 CASCADE 설정
  • 권장안은 changed_by INT NULL + ON DELETE SET NULL

점검 포인트

• 주요 실수 위험: 중복/키/예약어/무결성
• UNIQUE 제약 확인
  • UNIQUE 제약 추가로 설정 중복 방지
• 방향성/식별자 컬럼 인덱스
  • 고유값/찾기 쉬운 컬럼은 모두 UNIQUE + INDEX
  • 외래키(company_id, product_id 등)도 전부 INDEX 포함
• 예약어(reserved word) 회피
  • role은 MySQL 8.0 이상에서는 예약어로 처리
    • MySQL 8.0부터 USER ROLE(사용자 역할) 개념이 추가되면서 CREATE ROLE, GRANT ROLE, SET DEFAULT ROLE 등의 명령어가 도입됨
• NOT NULL vs. NULL
  • SET NULL이 필요한 외래 키 컬럼들은 NULL 허용
• 중요한 검색 컬럼에 인덱스 생성
• 수치 정밀도가 필요한 필드에는 FLOAT보다 DOUBLE
  • FLOAT과 DOUBLE은 둘 다 부동소수점(Floating-point) 형식으로 숫자를 저장하지만, 저장 용량과 정밀도에서 차이가 있음
  • DECIMAL(p,s) 쓰는 것도 좋음
    • MySQL 등 SQL에서 소수점을 포함한 고정 소수점 숫자 타입 정의 방식
    • p: 정밀도(precision) → 전체 자릿수 (소수점 포함)
    • s: 스케일(scale) → 소수점 오른쪽 자릿수
    • DECIMAL(5,4)는 총 5자리 숫자 중 소수점 뒤에 4자리를 가지며 소수점 앞에는 5 - 4 = 1자리만 사용할 수 있음 → 표현 가능한 범위: -9.9999 ~ 9.9999
    • FLOAT이나 DOUBLE은 근사값을 저장하므로, 정확한 소수 표현이 필요한 경우(예: 금액, 이율, 부피, 비율 등)에 DECIMAL이 적합
• ENUM 값 기본값 정의(DEFAULT)를 의미상 필요한 테이블에만 지정
• 로그성 테이블에서 DEFAULT 제거해 이력 데이터의 무의미 기본값 방지

FLOAT과 DOUBLE

• 둘 다 부동소수점(Floating-point) 형식으로 숫자를 저장하지만, 저장 용량과 정밀도에서 차이가 있음

바이트 크기 및 정밀도

타입	바이트 크기	유효 자릿수(Approximate Significant Digits)	표현 범위(대략)
FLOAT	4 byte	약 7자리	±3.4E38
DOUBLE	8 byte	약 15~16자리	±1.7E308

• FLOAT은 단정밀도(single precision) 부동소수점이며 유효숫자가 약 7자릿수까지만 정확히 저장됨
• DOUBLE은 배정밀도(double precision) 형식으로, 15~16자릿수까지 오차 없이 표현 가능
• 즉, FLOAT은 메모리를 절약하는 대신 정밀도가 떨어지고, DOUBLE은 더 많은 공간을 쓰지만 정확한 계산 결과를 제공함

정밀도 관리에서 DOUBLE이 유리한 이유

1. 유효숫자 범위가 넓음
   • FLOAT에 16777217을 저장하면 MySQL이 이를 근사치인 16777216으로 반올림
     • DOUBLE은 같은 값을 정확히 저장
2. 연산 누적 오차가 적음
   • 반복 연산(덧셈·곱셈 등)을 수행할 때 FLOAT은 오차 누적이 더 커질 수 있음 DOUBLE은 내부적으로 더 넓은 비트 수를 사용해 결과의 신뢰도가 높음
3. 데이터 범위가 넓음
   • FLOAT으로 표현할 수 없는 매우 큰 값이나 작은 값도 DOUBLE은 안전하게 표현할 수 있음

정리

• 실시간 그래프나 센서값처럼 메모리 절약이 중요하고 오차 영향이 적은 데이터 → FLOAT
• 분석, 통계, 추천 알고리즘 등 정밀한 수치 계산이 필요한 데이터 → DOUBLE
• 화폐나 회계 데이터 → DECIMAL (정확한 고정소수점 표현을 위해)
• 따라서 일반적인 정밀도 중심 설계에서는 DOUBLE이 더 유리하며, 데이터 크기가 중요한 경우에만 FLOAT을 선택하는 것이 좋음