DB 의 제약 조건 적절성(?)

Question

데이터베이스는 Unique, Cascade, Check 등 다양한 제약조건을 통해 데이터의 무결성(Integrity) 을 보장할 수 있습니다. 하지만 실무 프로젝트나 레거시 시스템을 분석하다 보면, 이러한 제약조건을 모두 배제하고 단순히 컬럼의 데이터 타입만 정의한 경우를 종종 마주합니다.아마도 개발 단계에서의 데이터 입력 편의성이나, 요구사항 변경에 따른 유연성 확보 등을 이유로 제약조건을 제외한 것으로 보입니다. 물론 클라이언트나 애플리케이션(서버) 계층에서 1차적인 검증을 거쳐 데이터가 들어오기는 합니다.하지만 제 생각은 조금 다릅니다. 서버 코드를 전면 리팩토링하거나, 언어를 변경(예: Spring → Nest.js) 하여 마이그레이션 하는 상황이 온다면, 기존 애플리케이션 레벨의 방어 로직이 깨질 위험이 있습니다. 이럴 때 DB 차원의 제약조건은 휴먼 에러 를 방지 하는 역할을 한다고 생각합니다. 따라서 가급적 활용 가능한 제약조건은 걸어두는 것이 옳다고 봅니다.이러한 제 견해가 실무의 유연성을 고려하지 못한, 너무 이론적인 생각일까요?

전뚱이인데요 · Accepted Answer

글쎄요.. 정말 정답은 없는거 같아요 저는 공공기관이나, 아니면 은행권에서 일해서 당연히 제약조건은 필수라고 생각했는데 (RDB) 주로 사용하다보니 항상 제약조건은 필수였습니다.그런데 B2C 에서 근무하는 다른 개발자들은 오히려 성능, 개발편의, 추후 운영에 유연하게 대처하기 위해서 제약 조건을 걸지 않고 개발하는걸 당연시 여기는 분들도 많았어요 저는 개인적인 생각으로 그럴거면 noSQL을 사용하고 말지 굳이 RDB를 사용해서 제약조건을 왜 안걸지 생각하는데.. 한가지 확실한건 개발편의를 위해서 제약조건을 걸지 않으면 나중에 반드시 그 대가를 치루게 되지 않을까 라는 생각을 해보고요결론적으로 저는 RDB를 사용하는거면 제약조건을 반드시 건다는게 제 의견이고요 만약 성능이나 추후 운영 편의성을 생각한다면 비용이 가능하다면 다중 쿼리 모델을 두어서 RDB 하나, NoSQL 하나 둘거에요 하나는 데이터 무결성을 위해서 두고 하나는 실제 서비스 하는 쿼리 모델로 사용하지 않을까.. 그런 생각도 합니다.입력 데이터는 RDB -> 동기화 -> NoSql 에서 실제 데이터 서비스를 하면데이터 무결성도 지킬 수 있고 운영 및 성능도 챙길 수 있죠

집킨 · Answer

그런 제약조건은 대부분 도메인 규칙에 해당합니다근데 문제는 디비에만 제약조건을 걸어놓으면 디비를 들여다보지 않는 이상 개발자가 코드만 보고 중요한 도메인 규칙을 놓쳐서 버그가 발생할 확률이 높아진다는 거죠그렇다고 코드에만 구현하고 디비에서 빼버리면개발자의 실수를 방지할수가 없습니다비싼 디비 자원으로 바보같은 짓을 하는거죠결론은 양쪽 다 해야합니다코드에선 이해와 오해의 방지를 위해,디비에선 실수 방지와 무결성을 위해

kmksk · Answer

소프트웨어 업데이트 주가기 짧은 상황에서 제약조건이 잔뜩 달린 디비는 수정하기 엄청 부담 스러워요. 자주 마이그레이션 할수도 있어요. 쿠팡 같은 회사에서 1~2시간 서버 점검 하는건 엄청난 손실로 이어져요.또한 ORM 이 정착 하면서 DB 는 이제 영속화 도구로 사용되며 의존성을 줄이고 있는 추세이기도 하구요.그럼 왜 nosql 안쓰냐 라고 의문이 들탠데 이건 개인적인 생각으로, 아직은 mysql 이 더 익숙 한 거겠죠.RDB 를 느슨하게 쓴다고 해서 nosql 을 써야 되는건 아니니까요.

엡실론 · Answer

제 의견도 비슷합니다. 간단하게 쓸 수 있는 제약 조건이라면 쓰는게 훨씬 더 이익입니다. 저희는 제약 조건만으로는 충분히 검출하지 못하는 문제도 있으니, 주기적으로 데이터 검사하는 파이프라인을 만들기도 하지만, 제약 조건으로 간단하게 아예 막을 수 있으면 그렇게 하는게 더 낫죠.제약 조건으로 인한 불편함은 지금 드는 생각으로는 2가지 정도 인데,간단한 테스트 케이스를 만들때도 테스트와는 별 상관 없는 제약조건을 모두 지켜가면서 만들어야 한다.수작업으로 오류난 데이터를 고치고 싶을 때, 제약조건으로 인해 과정이 좀 더 번거로워진다.1번의 경우는 라이브러리나 코드를 통해서 해결할 수 있고,2번의 경우는 24시간 운영되는 서비스는 저런 식으로 할 수 없기도 하고, 사실 웬만하면 수작업으로 안하는 게 좋기는 하죠. 하다못해 간단한 스크립트라도 만드는게 훨씬 더 안전합니다.

DB 의 제약 조건 적절성(?)

4개의 답변

Q&A 목록