추후 문제가 될 소지가 있는 것들은 프로그램 기획 단계에서 가능한 여러 다양한 상황을 고려해서 설계해야 된다. 왜 이런 부분을 깨닫게 됐는지 몇 가지 사례를 소개하겠다.

1, 상품 데이터

일반적인 경우 매체(네이버, 페이스북, 구글 등의 광고 플랫폼)에 특정 상품을 프로모션 하기 위해서는 각 매체에서 요구하는 포맷에 맞게 상품 정보를 담고있는 파일(EP)을 전달해야 한다. 이 때 매체에서 광고를 내보낼 때 해당 매체 시스템에서 불평하는 특수문자가 EP파일에서 상품명 등에 포함될 경우 오류가 발생, 불완전한 광고가 송출될 위험이 있을 수 있다. 보통의 e커머스 사이트라면 상품 데이터의 양이 EP파일에 어마어마하게 쌓일 것이므로 상품 데이터가 쌓인 상태에서 문제가 되는 특수문자를 뒤늦게 걸러내는 것은 리소스가 드는 일일 것이다. 이 때, 프로그램 설계에서 이런 부분을 고려했다면 초기에 데이터가 적재될 때 특수문자가 들어가는 상품들을 논리적으로 분류하는 전처리를 해두었을 수도 있고 혹은 유저가 문제가 될 소지가 있는 특수문자가 들어있는 상품명을 등록하려 할 때 얼럿 등으로 미리 알려서 문제를 미연에 방지한다면 광고 집행의 측면에서는 보다 무결한 데이터를 확보할 수 있을 것이다.

2. 테이블명

TBICEH1

TBICEHAUTH

TBICSM1

TBICSM1AUTH

위의 테이블명을 보고 어떤 테이블인지 추측할 수 있는가.

현업에서 저 정도의 이름은 아니지만 간혹 이름을 보고는 어떤 테이블인지 도저히 알 수 없는 테이블들이 있었다.

때문에 해당 테이블을 가금 사용할 때마다 해당 테이블의 의미를 반추해야만 했다. 초반에 모델링 시 테이블 이름도 되도록이면 명확한 이름을 짓는 것을 추천하고 싶다. 테이블이 생성된 후 비즈니스에서 중요한 테이블의 경우 여러 프로그램에서 해당 테이블을 참조한다. 예를 들어 수십 개의 프로그램에서 TBICEH1 이라는 이름의 테이블을 참조해서 쓰고 있다고 하자. 유지보수를 하다보니 해당 테이블명이 불명확해서 테이블명을 수정하고 싶을 때가 생길 수 있다. 그 때 무심코 테이블명을 수정했다간 이를 참조하고 있는 모든 프로그램의 연결 문자열을 수정해야 한다. 프로그램의 설계에 따라 이런 불상사는 피할 수도 있지만 어디까지나 뒤늦게 수정하기에는 너무 멀리와버린(?) 경우도 생길 수 있다는 얘기다.