굿민의 데이터 설계

우리는 같은 세상을 보고 있을까?

goodmean — Wed, 15 Oct 2025 18:01:13 +0900

길을 걷다 문득,

빨간 장미 한 송이를 바라보며 이런 생각이 들었다.

“나는 이 장미를 정말 빨갛다고 느끼고 있는 걸까?
혹시 내 눈에 보이는 이 색이,
다른 사람에겐 전혀 다른 색으로 보이고 있는 건 아닐까?”

우리는 모두 장미를 빨갛다고 말하지만,

정말 ‘같은 빨강’을 보고 있는 걸까?

뇌는 색을 ‘보는’ 것이 아니라, ‘만든다’

색은 과학적으로 말하면 빛의 파장이다.
빨간색은 약 620~750nm의 파장을 가지며,
이 빛이 눈의 망막에 도달하면,
우리는 그것을 ‘빨강’이라는 감각으로 인식한다.

하지만 이 감각은 눈에서 만들어지는 게 아니다.
빛을 해석하는 건 뇌다.
눈은 정보를 전달할 뿐,

‘빨강’이라는 감정은 뇌가 만들어낸다.

그러니까, 당신이 보는 ‘빨강’은

나의 ‘보라’ 일 수도 있다.

당신의 뇌와 나의 뇌는 다르게 작동한다

사람마다 눈 속 원추세포의 구조나 분포,
그리고 시각 피질의 반응 방식은 미묘하게 다르다.

그 차이는 우리가 알지 못한 채 존재한다.
왜냐하면 모두가 그 색을
“빨강”이라고 부르기로 약속했기 때문이다.

그래서 나는 빨간 장미를 보고,

당신은 보랏빛 장미를 보았을지도 모르는데도,
우리는 둘 다 “빨간 장미”라고 말한다.
말은 같지만, 감각은 다를 수 있다.

하지만 이 가설은, 과학적으로 증명할 수 없다

이 모든 생각은 결국 하나의 가설이다.

“사람은 모두 다르게 색을 지각하며,
그 차이는 언어로 덮여 있을 뿐이다.”

이 가설은 매력적이지만,

과학적으로는 증명할 수 없다.
우리는 서로의 뇌를 ‘감각의 관점’으로

비교할 수 없기 때문이다.

이런 종류의 명제를 철학에서는
검증 불가능한 가설(non-falsifiable statement)

이라고 부른다.
그러니 이건 결국,
논증할 수는 없지만 계속해서 상상할 수 있는 이야기다.

색약, 색맹이 근거가 될 수 있지 않을까?

반은 맞고 반은 틀리다고 할 수 있다.
왜냐하면 그것은 색을 ‘다르게 보는 것’이 아니라,
‘일부 색을 구분하지 못하는 것’이기 때문이다.

예를 들어, 적록색약의 경우
빨강과 초록이 같은 색처럼 보이거나, 잘 구별되지 않는다.
이건 뇌의 해석 차이라기보다,
망막의 특정 수용기 기능 부족에서 비롯된
생물학적 한계에 가깝다.

그럼에도 불구하고 이러한 사례는

우리가 생각보다 더 다양하게 세상을 인식하고 있다는

하나의 단서가 되어준다.

즉, 색약은 이 가설을 완전히 뒷받침하진 못하지만,
“감각은 결코 절대적이지 않다”는 점을 상기시켜 주는

유의미한 예라 할 수 있다.

그래서, 이건 나의 색으로 본 세상에 대한 이야기다

이 글은 하나의 과학 이론도, 실험 보고서도 아니다.
그저 내가 살아가며 문득 떠올린,
작은 물음에서 시작된 사유의 조각이다.

하지만 그 물음 하나로,
나는 세상이 조금 더 신비롭게 느껴졌고,
다른 사람의 시선을 상상하는 일이
조금 더 따뜻하게 다가왔다.

당신은 지금, 어떤 색의 세상을 살고 있나요?

전체url주소 데이터 저장 타입 크기

goodmean — Wed, 15 Oct 2025 17:57:18 +0900

결론 [Inference]

전체 URL(풀 URL) 저장 추천 규격
1. 일반 권장: VARCHAR(2048) 이상(UTF-8 기준)
2. 서버/프레임워크가 긴 URL을 허용하거나 내부 리다이렉트·서명 URL이 많은 경우: VARCHAR(4096) 또는 무제한 가변 문자열(예: PostgreSQL TEXT, MySQL TEXT/LONGTEXT, SQL Server NVARCHAR(MAX))
3. DB별 실무 가이드(안전값)
  - PostgreSQL: TEXT (길이 제한 없음; 성능상 VARCHAR(n)과 실질 차이 거의 없음) PostgreSQL
  - MySQL/MariaDB: VARCHAR(2048~4096) 또는 TEXT (행 크기·문자집합 고려) MySQL+1
  - SQL Server: NVARCHAR(2048~4096) 또는 NVARCHAR(MAX) (유니코드 필요 시) Microsoft Learn+1

한 줄 권고: “호환성과 인덱싱 편의”가 필요하면 VARCHAR(2048~4096), “최대 유연성”이 필요하면 무제한 가변형(TEXT/NVARCHAR(MAX))을 사용.

이유 [Official/Academic]

표준에는 URL 길이 상한이 없습니다.
- URI 일반 문법(RFC 3986)은 최대 길이를 정의하지 않습니다. IETF Datatracker
- HTTP 표준(RFC 9110/9112)도 요청라인/헤더에 대한 구체 상한을 규정하지 않고, 구현체가 “합리적 한도”를 둘 수 있음을 전제합니다. IETF Datatracker+1
그러나 웹서버(구현체) 기본값이 사실상의 한도를 만듭니다.
- Apache httpd: 요청라인 허용 기본값 LimitRequestLine 8190 바이트(약 8 KB). httpd.apache.org
- Nginx: 요청라인은 **클라이언트 헤더 버퍼 하나의 크기(기본 8 KB)**를 초과할 수 없음. nginx.org
- IIS: maxUrl 기본 4096바이트, maxQueryString 기본 2048바이트. Microsoft Learn
⇒ 실무에서는 2 KB~8 KB 수준이 “안전권”이며, 보수적으로는 2 KB(≈2048), 여유를 보려면 **4 KB(≈4096)**를 택합니다.
DBMS 선택 관점(문자열 타입과 길이 제약)
- PostgreSQL: TEXT와 VARCHAR(n)은 성능 차이가 사실상 없고(길이검사 정도만 추가), TEXT는 **“임의 길이”**를 저장 가능. 설계 단순화에 유리. PostgreSQL
- MySQL: VARCHAR는 행 크기(최대 65,535바이트)와 **문자집합 바이트 수(UTF-8 가변)**의 영향을 받음. 긴 URL이 빈번하면 TEXT도 고려. MySQL+1
- SQL Server: NVARCHAR(MAX)는 대용량(최대 2 GB) 저장 가능하나, 행당 고정 오버헤드 등 운영 특성 고려. 일반 필드는 NVARCHAR(2048~4096)가 실무 균형. Microsoft Learn+1

출처 [Official/Academic/News 구분]

[Official] RFC 3986 (URI): 길이 상한 미규정. IETF Datatracker
[Official] RFC 9110/9112 (HTTP): 구체 상한 대신 구현체 재량 언급. IETF Datatracker+1
[Official] Apache httpd 2.4: LimitRequestLine 기본 8190바이트. httpd.apache.org
[Official] Nginx core 모듈 문서: 요청라인=단일 버퍼(기본 8 KB) 초과 불가. nginx.org
[Official] Microsoft IIS requestLimits: maxUrl=4096, maxQueryString=2048(바이트) 기본. Microsoft Learn
[Official] PostgreSQL 문서(문자형): text와 varchar 성능 차이 거의 없음. PostgreSQL
[Official] MySQL 문서: VARCHAR 최대 길이와 행 크기 제약, 저장 방식. MySQL+1
[Official] SQL Server 문서: nvarchar(max)/용량·행 오버헤드 등. Microsoft Learn+1

요약 표 [Inference]

쓰임새권장 타입/크기비고

일반 웹서비스(호환성 중시)	VARCHAR(2048)	IIS 기본한계(4 KB URL, 2 KB 쿼리스트링)를 고려한 보수값. Microsoft Learn
긴 서명 URL/프록시/리다이렉트 많음	VARCHAR(4096)	Apache/Nginx의 8 KB 선을 일부 반영한 실무 타협. httpd.apache.org+1
길이 예측이 어려움, 최대 유연성	PostgreSQL TEXT / MySQL TEXT(또는 LONGTEXT) / SQL Server NVARCHAR(MAX)	포스트그레스는 TEXT가 가장 단순·권장에 가깝고, MySQL/SQL Server는 운영정책에 따라 선택. PostgreSQL+2MySQL+2
인덱싱 필요(프리픽스 인덱스 등)	VARCHAR(2048~4096) + 필요 시 프리픽스 인덱스	DB/엔진별 인덱스 길이 한도 고려(엔진 문서별 상이). [Inference]

추가 실무 팁 [Inference]

문자집합: URL은 퍼센트인코딩으로 길이가 늘어납니다(UTF-8 멀티바이트 포함). 가급적 UTF-8로 통일하고 바이트 기준 한도를 감안해 여유 길이를 잡으세요.
검증: 애플리케이션 레벨에서 RFC 3986 문법 검증과 최대 길이 검증을 함께 두고, 서버 한도(Apache/Nginx/IIS)와 DB 길이를 일치시켜 예외를 줄이세요. Microsoft Learn+3IETF Datatracker+3httpd.apache.org+3
인덱스 전략: 전체 URL에 인덱스가 꼭 필요하지 않다면, **정규화된 핵심 키(도메인, 경로 해시 등)**에 인덱스를 두고 원문 URL은 비인덱스 컬럼으로 저장하는 설계가 효율적입니다. [Inference]

신뢰도(Verification Summary)

표준(RFC)·공식 제품 문서 기반 권고이며, 상한 부재(표준) + 구현체 기본값(웹서버) + DB 타입 특성을 교차 확인했습니다.
수치형 “기본값”은 제품 버전/설정에 따라 달라질 수 있으므로, 운영 환경의 실제 설정값(Apache LimitRequestLine, Nginx large_client_header_buffers, IIS requestLimits)을 최종 확인하는 것이 안전합니다.

프롬프트 잘 작성하는 방법

goodmean — Thu, 19 Sep 2024 20:32:08 +0900

프롬프트 잘 작성하는 방법

1. 질문이 명확하고 구체적이어야 한다.

"내일 어때?" : 뭘 물어보는건지 모른다.

"내일 주식시장 어때?" : 뭘 물어보는 건지는 알겠다. 질문은 조금 더 명확해졌다.

"내일 주식시장에 영향을 줄만한 주요 이벤트는 뭐가 있지?" : 좀더 구체적이다.

"내일 주식시장 관련 주요 이벤트를 시간 순서대로 정리해줘." : 원하는게 조금 더 구체적이 되었다.

2. 배경 정보를 포함하면 좋다.

참고할만한 자료가 있는지를 알려주면 좋다.

"Investing.com의 이벤트 캘린더를 기반으로 내일 주식시장 관련 이벤트를 정리해줘"

3. 간결함

프롬프트가 너무 길어지면 끊어서 요구하면 좋다.

"이벤트 캘린더에서 내일 주식시장 관련 이벤트를 정리하고 그 다음 시간 순서대로 나열해줘"

보다는

Investing.com에서 이벤트 캘린더의 정보를 수집해달라.

내일 이벤트만 정리해달라.

시간 순서대로 나열해달라.

이걸 순차적으로 수행해달라.

4. 열린 질문을 사용한다.

단순히 '예', '아니오'로 대답할수 있는 질문 보다는 많은 정보를 제공할수 있는 질문을 한다.

5. 명확한 목표를 설정한다.

"주식시장 이벤트의 결과에 따라 주식시장에 미칠 영향을 요약하여 설명해주세요."

6. 언어와 문체

용도에 맞는 적합한 언어와 문체를 설정한다.

"애널리스트 처럼 알려주세요."

"친구에게 이야기 하듯이 설명해주세요"

" OO 보고서에 대한 전문적인 요약을 해준다고 가정하고 답변해주세요."

그외에도 팁은 정말 많이 있다.

이 분야에서 가장 잘 정리된 글은 '인지적 프롬프팅'에 있으니 읽어 볼것

https://docs.google.com/presentation/d/1kayepoiTVT838Tetk02nxeqVmmS9BDc9O7n-4OzJdL8/edit?pli=1

[Axure] 드롭박스 값에 따라 액션 주기

goodmean — Tue, 18 Jun 2024 11:12:45 +0900

드롭박스 선택 후 인터렉션 SELECTION CHANGED 선택
SELECTION CHANGED 옆의 Enable Cases 클릭

3. Add Rogic 클릭 후 원하는 값 선택

4. 그 후 아래와 같이 조건문이 걸렸다면

5. 원하는 액션을 설정하시면 됩니다.

ex ) 메일 드롭리스트로 선택 시 해당 값을 그대로 입력(Set Text) 하게 해주는 조건문.

여부 컬럼의 개요/표준

goodmean — Fri, 8 Mar 2024 11:51:12 +0900

여부 칼럼 #1: 개요/표준

데이터 모델을 작성시 많이 나타나는 속성 중에 하나가 여부속성 즉 여부컬럼이다.
여부 컬럼은 테이블상에 보통 _YN, _FLAG 로 끝나는 컬럼이다.
모델링을 할 때 마다 여부 컬럼을 어떻게 구현할까 항상 고민 거리가 되는 부분이다.
심한 경우 한 테이블에 여부 컬럼이 백여 개 이상인 것들도 존재 한다.
상황에 따라 모델 구성이 제 각각으로 이루어 질 수 있다고 하지만, 가만히 그 내부를 살펴보면 몇 가지 규칙및 패턴이 있을 것이다.
이제 모델링 프로젝트에 투입시에 매번 똑 같은 고민을 하지 말고 패턴을 잘 적용하여 좀 더 알차게 적용해 보자.

여부 컬럼 예시

여부 컬럼들은 주로 핵심 혹은 메인 테이블에서 발생하곤 한다.

어떤 여부 컬럼들이 있을까 한번 나열해 볼까.
아래는 상품 테이블 에서 봄직 한 속성들이다.

사용여부 / 특별상품여부 / 대표상품여부 / 주문불가여부 / 판매여부 / 품절여부 / 재판매제한여부
설치상품여부 / 가격노출여부 / 비교가격표시여부 / 무료판매여부 /적립금제한여부 / 할인금적용여부
일시불할인제한여부 / 즉시적립금할인제한여부 / 방송자동적립금제한여부 / 프로모션제한여부
쿠폰할인액노출여부 / 포인트미부여여부 / 제휴특판제한여부 / 제휴할인제한여부
카드사용제한여부 / 주문제작여부 / 예약판매상품여부 / 예약주문가능여부 / 소형상품여부
방송중판매가능여부 / 방송제휴여부 / 반복구매여부 / 성인인증여부 / 삼성상품여부
배송제한여부 / 반품불가여부 / 정보수정불가여부 / 매장진열여부 / 세금계산서발행여부
특소세여부 / 사은품여부 / 이미지확인여부 / 자동주문가능여부 / 편의점택배반품여부
센터추가포장여부 / 유료배송여부 / 당일배송가능여부 / 당일배송여부
당일배송체크여부 / 유료배송추가여부 / 지정택배시행여부 / 교환반품유료여부
속성상품가격여부 / 판매종료여부 / 정품여부 / 균일가상품여부 / 결품알람여부
상품응대대상여부 / 당사상품권여부 / 인터페이스여부 / 방송상품여부
직원용상품여부 / 전시여부 / 승인여부 / 재고유무 / 포장가능여부 / 나이제한여부 /해외배송가능여부
신규여부 / 세일표기여부 / 쿠폰표기여부 / 포인트표기여부 / 카드할인표기여부 / 카드가능여부

어떤가 어지럽다. . . .

해당 속성 마다 제 고유의 비즈니스 로직도 함께 녹아져 있으니 속성의 참 뜻을 이해하기란 상당히 어렵다. 하나의 테이블에 있는 속성이라고 하더라도 개발 담당하였던 시기가 다를 때 한사람이 모든 여부 컬럼의 목적과 활용도를 알기는 쉽지 않다.

여부 컬럼들은 그 사용 목적에 따라 여러 가지 유형이 존재 할 수 있다.

1)중복 속성

- 다른 테이블의 결과만을 요약형태로 갖는 경우 (처리여부)
배치처리 및 후속 처리의 결과 값으로 활용된다.
- 부모테이블에 자식테이블 데이터가 있다 없다 표기하는 경우 (존재여부/예약여부)
- 동일테이블의 컬럼에 대한 이중 표현
승인일시의 값이 있다, 없다 로 표현할 수 있지만 여부컬럼을 부수적으로 사용할 수 있다.
(요일상품여부 + 적용요일코드) (승인여부 + 승인일시) (원본여부 + 원본코드)
(전송여부+ 전송일시)

2) 데이터 분류용, 데이터 개체의 정의로 사용되는 속성

- 서브타입 역할을 하는 것 (품목여부/해외상품여부,거래처여부,판매처여부)
- 테이블의 구성을 알려주는 역할 (복사된상품여부 / 삭제여부)

3) 제어용 속성으로서 로직 처리 하기 위함

- 어플리케이션에서 특정 데이터만을 위한 예외 처리 (사용여부/무료여부)
- 제한 및 제약을 두기 위한 처리 (특판제한여부, 반품불가여부,카드가능여부 )
가능, 불가를 표현하기 위한 것

4) 성능을 위한 속성

- 이벤트 및 거래 액션의 결과 중에서 마크가 필요한 것 : 품절여부
- 요약용 컬럼 : 프로모션중여부, 사은품있음여부
중복속성과 유사한 성격이라고 할 수 있다.

5) 코드를 여부로 나열한 속성

- M개의 값을 YN으로 표기 하는 경우 (취미코드 : 바둑여부, 게임여부, 스포츠여부,..)
- 정규화에 의해서 다른 테이블로 분리가능 한 속성들.

6) 기타

- 아주 다양한 사연을 담고 있는 여부 컬럼들이 있겠다…

여부 컬럼 하나 하나의 사례는 기회가 되면 작성해 보도록 하고
여기서는 여부 컬럼들을 모델에 표현 하는 방법을 생각해 보고자 한다.

여부 컬럼의 표준화

여부 컬럼들은 실제 데이터 모델에서는 어떻게 사용되고 있을까

1) 표준화된 명칭

- 일반적으로 속성분류어로서 일관성 있게 사용한다. 여부, 플래그, 유무라고 표현된다.

OO여부->00_YN
00플래그 ->00_FLAG

2) 물리적 세팅

- NOT NULL 화 시키고, 디폴트 값을 부여한다.

< 의견 >
여부 컬럼은 NULL 컬럼 많고, 디폴트 값을 부여하지 않은 시스템들이 많다.
하지만 본인은 DB에서 강제하는 것을 선호한다.
시간이 흘러 여러 담당자가 바뀌다 보면 해당 컬럼의 초기값과 의미를 프로그램 소스를 열어 보아야만 알 수 있는 상황이 온다. 누구나 테이블에 세팅된 값을 보고 직관적으로 이해 할 수 있도록 DB에 세팅하는 것이 좋겠다.

- 물론 운영중에 추가되는 여부 컬럼은 NULL 허용이 많다.
기존 데이터는 영향 받지 않고 신규 데이터 혹은 특정 조건 일때만 사용되기 때문이다.
또한 NOT NULL 처리시 데이터 사이즈가 클 경우 디폴트 값을 세팅하는데 오랜 시간이 걸릴 수 있다.

- 프로젝트 진행시 초기에 모델표준에서 여부 컬럼에 대한 사용을 정의해 놓지 않으면 , 개발 및 이행단계에서는 NOT NULL 화 처리 하지 못하고 NULL 허용으로 그대로 가는 경우가 있다.
또 NOT NULL 처리는 입력 및 수정 프로그램의 수정이 필요하기 때문에 영향도 파악이 쉽지 않을 수 있다.

3) NOT NULL 화 할 수 없는 여부 컬럼

모든 여부 컬럼을 NOT NULL 화 시켜야 할까 특정 컬럼은 NULL이 올 수 밖에 없는가

[상품테이블][카드가능여부] 컬럼의 값을 보자

Y:100건
N:200건
NULL :700건

업무규칙은 Y이면 상품 구매시 카드를 사용할 수 있다.
N이면 카드 사용 불가 이다.
NULL이면 아직 세팅된 값이 없지만 카드 사용 불가 이다.
N 과 NULL은 동일 업무 규칙을 따른다.
단지 판단 할 수 있는 것은 값이 변경 이력인데 처음에 여부 값은 [ NULL ] 이였다가 카드사용이 가능해 졌을때 [ Y ]로 변경되고 이후 다시 [ N ] 로 변경되었음을 짐작 할 수 있다.
컬럼값의 변경을 위한 추적이라면 이력 혹은 로그 관리를 해야 한다.

변경이 한번도 없었던 값이라는 의미로서의 NULL 값을 유지 할 필요성이 많지 않다.

모델 내린다는 것은 위험한 일이지만 생각을 단순화하는 차원에서 NOT NULL 화 시키고, 예외가 되는 부분은 NULL 허용이라는 규칙을 가져가는 것이 좋겠다.

( 예외 : YN에 인덱스를 생성하는 경우,데이터 사이즈를 조금이라고 줄이려는 경우 등)

4) 테이터 값 검증

여부 컬럼의 데이터 값은 어떻게 세팅 되는가

가) Y/N : 긍정의 의미로서 Y, 부정의 의미로서 N
일반적인 데이터 세팅이다. 표준은 YN으로 세팅하는 것이 좋겠다.

나) 1/0 : 긍정의 의미로서 1, 부정의 의미로서 0
고전적인 표기법이라고 할 수 있으며 비트연산을 고려해서 만들 수도 있겠다.
추천하지는 않는다.

다) NULL : NULL은 가급적 없애자. 특히 핵심/메인/마스터 테이블에서는.
마스터 테이블의 NULL값을 여러 시스템, 서로 다른 개발자가 다른 값으로 치환하는 경우를 간혹 볼 수있다.A프로그램에서는 NVL(카드가능여부,’Y’)B프로그램에서는 NVL(카드가능여부,’N’)로 작성 할 오류 가능성도 존재한다.

라)1/2 : 이건 모죠
혹 Y/N을 1/2로 표현한 사이트도 있지 않을까 싶어서 만들어 보았다 (웃으시고…)

마)Y/N/Y/Z : 허억, 이건 또 모냐
여부 컬럼에 왜 이리 값이 많은 것일까
컬럼이 미쳤어 ~ 미쳤어.. 에고 돌아 보려 ~~~
추측 1 ) Y/Z는 오류 값이다. YN이어야 만 한다. 이런 데이터는 클린징이 필요하다.
추측 2 ) 여부 컬럼의 개념이 확장 되었다. 처음에는 YN 값만 있었는데, 세월이 지나고 시스템이 성장하면서 의미가 확장 될 수 있다.

[ 사용여부 ]

Y : 사용
N : 미사용
Y : 삭제a 미사용은 화면에 보이는데 아예 삭제된 데이터를 표기하고자 함
Z : 검토중a 주요 속성이라서 검토/승인 프로세스 진행이라는 것을 표기

물론 이렇게 개념이 확장 된 것은 이제 컬럼명은 사용여부 이지만 도메인은 사용유형코드로 변경되어야 한다. 여부컬럼이 코드컬럼으로 진화한 경우라고 볼 수 있겠다.
( 컬럼명은 변경하기 어려울 것이다. 이미 모든 프로그램에 적용되어 있을 테니…)

5) 이해가 편한 한글속성 표기

여부 컬럼도 한글속성명과 영문컬럼명을 잘 만들어 주어야 한다.
이름이 너무 어려우면 매번 머리에서 2번 고민을 해야 의미를 알 수 있는 컬럼 들이 있다.

- 무검사여부 : YN

Y : 제품에 대한 정밀검사를 하지 않았다는 의미. 즉 검사하지 않아도 되는 제품이다.
N : 제룸에 대한 정밀검사를 하지 않으면 안된다는 의미. 즉 검사를 반드시 해야하는 제품

위 컬럼은 몇 일 지나면 반드시 또 헷갈린다.

컬럼을 이렇게 바꾼다 e 검사여부 : YN

- 신용카드사용불가여부 : YN

Y : 신용카드를 사용할 수 없는 제품이다
N : 신용카드를 사용할 수 있는 제품이다

성공과 행복의 원천은 긍정적인 마음자세라고 한다
. 컬럼도 마찬가지다. 긍적적인 표현을 사용하자

컬럼을 이렇게 바꾼다 e 신용카드가능여부 : YN

- 적립금제한여부 : YN

Y : 적립금을 줄 수 없는 상품이다
N : 적립금을 줄 수 있는 상품이다

컬럼을 이렇게 바꾼다 e 적립금가능여부 : YN

사람마다 다르겠지만 혹 제한의 의미를 더욱 강조해야만 하는 경우에는 제한여부를 사용할 수도 있겠다. 판단은 모델러에게 > 다른 관련자들의 합의하에 결정하면 된다.

다음은 NOT NULL화 되지 않는 컬럼들에서 나타나는 NVL() 처리 예시이다

SELECT C.PRD_CD
,C.PRD_NM AS PRD_NM
,NVL(C.CHR_DLV_YN, 'N') AS CHARGE_FLAG========> 여부가 NULL 처리 : N으로 바뀐다
. ,CASE WHEN NVL(C.CHR_DLVC_CD, 0) > 0 THEN
,NVL(B.SALE_PRC, 0) AS KHS_PRICE========> 금액 NULL 처리 0으로 바뀐다.
FROM배송 D
,상품 C
,가격 B
WHEREA.PRD_CD = B.PRD_CD
ANDA.PRD_CD = C.PRD_CD
ANDC.SUP_CD = D.SUP_CD
ANDVALID_STR_DTM <= SYSDATE AND VALID_END_DTM > SYSDATE
ANDA.GUBUN = 'L'
ANDA.RANKING <= 20
ANDNVL(C.REP_YN,'N') <> 'Y'========> 여부가 NULL 처리 N으로 바뀐다.
ANDNVL(C.CARD_USE_LIMIT_YN, 'Y') <> 'N'========> 여부가 NULL 처리 Y로바뀐다.
ANDC.GBN_CD <> '10')

행여 여부 컬럼이 인덱스 대상 컬럼이라면 NVL()로 인한 가공으로 인하여 인덱스를 최적으로 사용하지 못할 수도 있겠다.

출처 : https://dataonair.or.kr/

일반회원 테이블과 휴면회원 테이블을 따로 만드는 이유

goodmean — Wed, 13 Dec 2023 17:11:08 +0900

일반회원 테이블과 휴면회원 테이블의 컬럼은 완전히 동일한데 따로 만드는 이유가 무엇일까요?
상태값만 바꿔주면 편하지 않을까요?

결론부터 말하자면 지금은 따로 만들 필요가 없습니다.

2020년 2월 4일 부로 정보통신망법 제29조가 사라졌기 때문입니다.

이전에 테이블을 분리했던 이유는 정보통신망법 제 29조에 있었습니다.

② 정보통신서비스 제공자등은 정보통신서비스를 1년의 기간 동안 이용하지 아니하는 이용자의 개인정보를 보호하기 위하여 대통령령으로 정하는 바에 따라 개인정보의 파기 등 필요한 조치를 취하여야 한다. 다만, 그 기간에 대하여 다른 법령 또는 이용자의 요청에 따라 달리 정한 경우에는 그에 따른다. <신설 2012.2.17, 2015.12.1>
③ 정보통신서비스 제공자등은 제2항의 기간 만료 30일 전까지 개인정보가 파기되는 사실, 기간 만료일 및 파기되는 개인정보의 항목 등 대통령령으로 정하는 사항을 전자우편 등 대통령령으로 정하는 방법으로 이용자에게 알려야 한다.

1년 이상 서비스 이용 기록이 없는 이용자의 회원가입 정보는 정보통신망법 제29조에 따라 일반 이용자의 회원가입 정보와 분리하여 별도로 저장 및 관리되며, 휴면회원으로 전환되기전 30일 전까지도 알려야 했죠.

하지만 해당 법조항이 사라진 이후엔 법적으로 분리하지 않아도 되고, 현재도 분리하고 있는 이유는 회원가입 정책에 회사가 해당내용을 기재했을 가능성이 높습니다.

[MySQL] 날짜 차이 구하기

goodmean — Wed, 15 Feb 2023 13:42:01 +0900

함수	내용
DATEDIFF(날짜1, 날짜2)	날짜1 - 날짜2 차이를 일수로 반환
TIMESTAMPDIFF(단위, 날짜1, 날짜2)	날짜1 - 날짜2 차이를 선택한 단위로 반환

SECOND	초
MINUTE	분
HOUR	시
DAY	일
WEEK	주
MONTH	월
QUARTER	분기
YEAR	년

DATEDIFF

쿼리 : SELECT DATEDIFF('2021-01-16', '2017-03-01');
결과 : 1417

TIMESTAMPDIFF

쿼리 : SELECT TIMESTAMPDIFF(QUARTER, '2021-09-22', '2020-03-28');
결과 : -5

[MySQL] IF, CASE, IFNULL

goodmean — Wed, 15 Feb 2023 13:39:35 +0900

IF (조건문, 참일때 값, 거짓일 때 값)

CASE

CASE
	WHEN 조건1 THEN '조건1 반환값'
    WHEN 조건2 THEN '조건2 반환값'
    ELSE '충족되는 조건 없을 때 반환값'
END

IFNULL

IFNULL( 값1, 값1이 NULL이면 출력하는 값 )

[MySQL] 암,복호화 함수

goodmean — Wed, 15 Feb 2023 13:35:22 +0900

mysql에서 제공하는 함수

암호화 & 인코딩

#암호화
AES_ENCRYPT({암호화 할 값},{암호화 키})

#인코딩
TO_BASE64(AES_ENCRYPT({암호화 할 값},{암호화 키}))  #BASE64로 인코딩
HEX(AES_ENCRYPT({암호화 할 값},{암호화 키})) #hexadecimal string으로 인코딩

#EXAMPLE
UPDATE MEMBER
   SET MEM_NAME_ENC = TO_BASE64(AES_ENCRYPT(MEM_NAME,'testkey123'));

복호화 & 디코딩

#디코딩
FROM_BASE64({암호화된 값})
HEX({암호화된 값})

#복호화
AES_DECRYPT(FROM_BASE64({암호화된 값}), {암호화 키}) # 암호화 할 때 사용했던 키 사용

#EXAMPLE
SELECT CAST(AES_DECRYPT(FROM_BASE64(MEM_NAME_ENC), 'testkey123') AS CHAR(50)) AS MEM_NAME
  FROM MEMBER;

SELECT CONVERT(AES_DECRYPT(FROM_BASE64(MEM_NAME_ENC), 'testkey123') using UTF-8) AS MEM_NAME
  FROM MEMBER;

예시

## 1. hex 테스트 - 숫자
SELECT HEX(AES_ENCRYPT(123,'testkey123')) AS '암호화';
# 8DA6C1BCE3FC76CE3BA5DCF2AE0C6C71

SELECT AES_DECRYPT(unhex('8DA6C1BCE3FC76CE3BA5DCF2AE0C6C71'), 'testkey123') as '복호화';
# 123


## 2. hex 테스트 - 문자열
SELECT HEX(AES_ENCRYPT('abc-가나다','testkey123')) AS '암호화';
# 34B7FC91EA42901201A23730EDA93B8E

# 한글을 포함하는 문자열은 추가적인 변환 작업이 필요하다.
SELECT CONVERT(AES_DECRYPT(UNHEX('34B7FC91EA42901201A23730EDA93B8E'), 'testkey123') USING UTF8) AS '복호화';
SELECT CAST(AES_DECRYPT(UNHEX('34B7FC91EA42901201A23730EDA93B8E'), 'testkey123') AS CHAR(50)) AS '복호화';
# abc-가나다


## 3. BASE64 테스트 - 숫자
SELECT TO_BASE64(AES_ENCRYPT(123,'testkey123')) AS '암호화';
# jabBvOP8ds47pdzyrgxscQ==

SELECT AES_DECRYPT(FROM_BASE64('jabBvOP8ds47pdzyrgxscQ=='), 'testkey123') AS '복호화';
# 123


## 4. BASE64 테스트 - 문자열
SELECT TO_BASE64(AES_ENCRYPT('abc-가나다','testkey123')) AS '암호화';
# NLf8kepCkBIBojcw7ak7jg==

# 한글을 포함하는 문자열은 추가적인 변환 작업이 필요하다. 
SELECT CONVERT(AES_DECRYPT(FROM_BASE64('NLf8kepCkBIBojcw7ak7jg=='), 'testkey123') USING UTF8) AS '복호화';
# abc-가나다


# 5. table 조회 예시
SELECT AES_DECRYPT(FROM_BASE64(MEM_BIRTHDAY_ENC), 'testkey123') AS '생년월일'
     , CONVERT(AES_DECRYPT(FROM_BASE64(MEM_NAME_ENC), 'testkey123') USING UTF8) AS '이름1'
     , CAST(AES_DECRYPT(FROM_BASE64(MEM_ADDRESS_ENC), 'testkey123') AS CHAR(50) ) AS '이름21'
  FROM MEMBER;

[MySQL] 날짜, 시간 간의 차이 함수

goodmean — Mon, 6 Feb 2023 11:50:34 +0900

MySQL에서 두 날짜간의 차이를 가져올 때 사용하는 함수가 두 가지가 있습니다.

단순히 일 차이를 가져올 때 사용하는 것이 DATEDIFF 함수입니다.

이 외에도 차이를 연, 분기, 월, 주, 일, 시, 분, 초를 지정하여 가져올 때 사용하는 함수가 TIMESTAMPDIFF 함수입니다.

▶사용법

DATEDIFF

DATEDIFF(날짜1, 날짜2);

* 간단히 말하자면 날짜1 - 날짜2 동작입니다.

TIMESTAMPDIFF

TIMESTAMPDIFF(단위, 날짜1, 날짜2);

단위

SECOND : 초
MINUTE : 분
HOUR : 시
DAY : 일
WEEK : 주
MONTH : 월
QUARTER : 분기
YEAR : 연

▶예제 쿼리 (Example Query)

DATEDIFF 예제1

쿼리

SELECT TIMESTAMPDIFF(QUARTER, '2017-03-01', '2018-03-28');

결과

392

DATEDIFF 예제2

쿼리

SELECT DATEDIFF('2018-03-28 23:59:59', '2017-03-01 00:00:00');

결과

392

TIMESTAMPDIFF : 초

쿼리

SELECT TIMESTAMPDIFF(SECOND, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(SECOND, '2017-03-01 00:00:00', '2018-03-28 00:00:00');

결과

33868800

TIMESTAMPDIFF : 분

쿼리

SELECT TIMESTAMPDIFF(MINUTE, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(MINUTE, '2017-03-01 00:00:00', '2018-03-28 00:00:00');

결과

564480

TIMESTAMPDIFF : 시

쿼리

SELECT TIMESTAMPDIFF(HOUR, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(HOUR, '2017-03-01 00:00:00', '2018-03-28 00:00:00');

결과

9408

TIMESTAMPDIFF : 일

쿼리

SELECT TIMESTAMPDIFF(DAY, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(DAY, '2017-03-01 00:00:00', '2018-03-28 00:00:00');

결과

392

TIMESTAMPDIFF : 주

쿼리

SELECT TIMESTAMPDIFF(WEEK, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(WEEK, '2017-03-01 00:00:00', '2018-03-28 00:00:00');

결과

TIMESTAMPDIFF : 월

쿼리

SELECT TIMESTAMPDIFF(MONTH, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(MONTH, '2017-03-01 00:00:00', '2018-03-28 00:00:00');

결과

TIMESTAMPDIFF : 분기

쿼리

SELECT TIMESTAMPDIFF(QUARTER, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(QUARTER, '2017-03-01 00:00:00', '2018-03-28 00:00:00');

결과

TIMESTAMPDIFF : 연

쿼리

SELECT TIMESTAMPDIFF(YEAR, '2017-03-01', '2018-03-28');
-- SELECT TIMESTAMPDIFF(YEAR, '2017-03-01 00:00:00', '2018-03-28 00:00:00');