Architecture16 Number와 boolean 은 최대한 Not Null로 선언하기 테이블 설계시 종종 받는 질문 중 하나가 Boolean과 Number 컬럼의 Not Null 유무이다. 비즈니스적으로 기본값이 있는 경우가 아니면 유연하게 하기 위해 nullable 로 선언하는 경우를 자주 본다. 테이블의 Boolean과 Number 타입 컬럼을 nullable 로 설정하면 여러 문제가 발생할 수 있어서 가급적 추천하지 않는다. 대표적으로 다음과 같은 문제가 있다. 1. 혼란스러운 의미 컬럼을 nullable 로 설정하면 기본값이 null 이 되므로, 데이터의 의미가 굉장히 혼란스럽게 된다. 예를 들어, boolean 컬럼이면 값이 true, false, null 세 가지 상태가 될 수 있다. 이는 '참', '거짓', '미확인' 의 세 가지 상태가 된다는 것이다. (일부 상황에서는 유용.. 2023. 6. 2. 1. 효율적으로 로그 모니터링하기 - 로그 레벨 구분하기 365/24 로 관리하는 시스템에서 로그는 굉장히 중요하다. 하지만 로그가 중요하다는 생각에 무분별하게 남기는 것은 좋지 않다. 대표적인 예로 습관적으로 예외 상황이 발생하면 ERROR 레벨로 로그를 남기는 경우이다. 보통의 서비스에서는 시간 내 에러 로그가 일정 수치 이상 쌓이면 알람을 발생시키도록 구성한다. 정상적이지 않은 모든 상황에서 전부 ERROR 레벨로 처리하게 되면 불필요하게 많은 알람들로 인해 정작 봐야할 심각한 에러 로그들도 놓칠 수 있다. 그래서 적정 수준에서 로그 레벨을 구분하여 알람 경보 수준도 구분하는 것이 필요하다. 1. 로그 레벨 로그 레벨은 해당 로그 메세지가 얼마나 중요한지를 알려주는 정보이다. 로그 레벨의 중요도는 담당 개발자가 밤에 계속 잠을 잘 수 있는지, 즉시 침대에.. 2023. 4. 16. 2. 좋은 함수 만들기 - 암묵적 입력/출력 지난 시간에 부작용 (부수효과) 함수에서 어떻게 최대한 부작용과 거리두기를 해서 좋은 함수를 만드는지 간단한 예제로 연습해봤다. 이번 시간에는 좋은 함수가 되기 위해 관리해야할 부작용이란 어떤 것들이 있는지 알아보자. 1. 암묵적 입력/출력 좋은 함수는 "부작용 (부수효과) 이 없으며, 멱등성을 유지할 수 있는 함수" 라고 했다. 이 부작용 (부수효과) 함수에는 크게 2가지 특징이 있다. 암묵적 입력 (implicit input) 암묵적 출력 (implicit output) 1-1. 암묵적 입력 (implicit input) 암묵적 입력이란 함수의 입력값으로 명시적으로 전달되지 않는 파라미터를 의미한다. 예를 들자면 다음과 같은 경우 암묵적 입력이다. 함수의 인자는 없는데 함수 내부에서 쿠키에서 값을 가.. 2023. 3. 1. 1. 좋은 함수 만들기 - 부작용과 거리두기 요즘의 개발에서 프레임워크나 라이브러리 사용이 없는 개발은 생각하기 어렵다. 특히 DDD 등의 개념까지 기본지식처럼 취급되어 점점 추상화된 개발에 익숙해지고 있다. 복잡한 애플리케이션 구현을 하다보면 이러한 것들에 대해 당연히 필요하다. 다만, 이게 심해지다보면 실제 구현을 해야할 변수, 함수, 클래스 등을 잘 작성하는 것보다 프레임워크나 라이브러리의 기능을 얼마나 많이 알고 있느냐를 개발자의 성장으로 오해할 수도 있다. 프레임워크와 라이브버리와 같은 도구에 대해서 숙련도가 높다면 당연히 좋겠지만, 그 이전에 좋은 변수, 함수, 클래스에 대해 먼저 고민하는 것도 필요하다. 그래서 이번 시리즈에서는 좋은 함수에 대해서 이야기하려고 한다. JS/TS 환경에서 불변객체 다루는 방법이 순수 함수형 언어들에 비해.. 2023. 1. 18. 데이터 변환 계층 (Data Transform Layer) Express와 JS/TS만을 가지고 프로젝트를 진행하다보면 데이터 변환 계층의 기준이 정해져있지 않은 경우를 많이 본다. 사람마다 다르기도 하고, 혹은 같은 사람이 작성한 코드에도 천차만별이다. 이에 대해서는 팀에서 확실하게 컨벤션을 잡지 않으면 서로 데이터 변환 계층을 다르게 두어 프로젝트 전체가 일관성이 떨어지고 코드 가독성과 리팩토링 내성도 떨어지게 된다. 그렇다면 데이터 변환 계층의 기준을 어떻게 세우면 좋을까? 문제 예를 들어 다음과 같은 상황이 있다고 해보자. 프로젝트에서는 js-joda (혹은 Dayjs 등) 날짜 타입을 쓰고 있는 상황에서 Database SQL에서 사용하기 위해서는 Date 로 치환해야하는 경우 API 로 외부에 데이터를 전송 (혹은 요청) 하기 위해 String 으로 .. 2022. 11. 28. 현실 세계의 속성에 의존하지 않기 최근에 들었던 질문 중 현실 세계의 식별자를 데이터베이스 기본키로 써도 되냐는 것이 있었다. 이를테면 현실 세계에서 유일함을 보장하는 값들이다. 주민 등록 번호 전화 번호 여권 번호 이들을 데이터베이스의 기본키 (PK) 로 지정해서 쓰는게 어떤가 하는 것이다. 최근의 ORM 예제들을 보면 auto_increment 혹은 uuid 등 개발자가 직접 생성한 기본키을 지정하는데, 왜 그렇게 하는지 모르겠다는 이야기도 들었다. (나 뿐만 아니라 여러 개발자분들이 같은 생각을 하실것 같은데) 기본키는 절대 바뀌지 않아야 한다. 기본키를 수정하는 것은 항상 많은 문제를 일으킨다. 대부분의 기본키가 여러 테이블의 FK와 인덱스로 지정되어 사용되기 때문이다. 더군다나 위와 같이 현실 세계의 값들은 사용자들이 직접 입력.. 2022. 5. 31. 이전 1 2 3 다음
