db 외래키 실무에서 안쓰나요

Question

안녕하세용.db 테이블 건드려보는 거 허락받은 허접입니다.개발 서버 한정이지만... 아무튼제목 그대로 실무에서 외래키 안쓰는 경우가 더 일반적인지 궁금합니다.외래키 관련해서 제가 찾아본 바로는 대략 이런 내용인 거 같은데추가로 알아야 할 게 있는 지 알려주시면 감사하겠습니다.1. 성능 문제도 있고, 어차피 어플리케이션 단에서 유효성검사 다 하기도 해서 굳이 안한다.2. 개발 편의성외래키 존재 시 반드시 부모 테이블이 존재해야 하고, 삭제할 땐 또 자식부터 지워야 하고 등등...개발하고 테스트할 때 불편함3. 생각보다 별로 쓸모 없음어차피 삭제라고 해봐야 보통 삭제용 컬럼 (USED=0) 을 이용해서 논리적 삭제만 해서개인정보같이 진짜 지워야 하는 건 얼마 없어서외래키가 유의미하게 쓰일 일도 잘 없음.

하루의_spring · Answer

테이블 많아지면 왜래키 떄문에 삭제하고 싶어도 못삭제하는 웃지못할 일이 발생할 수 있습니다 물론 외래키 있으면 좋습니다만 .. 테이블이 수백개의 모든 테이블의 관리를 하기란 어렵습니다

MSSQL 튜너 · Answer

저는 보통 중요 테이블, 마스터 디테일 구조에서만 가끔 신경 씁니다

엄마미안 · Answer

내가 만든 시스템이 외래키의 도움이 없어도 정합성을 유지할 정도로 견고할 자신 있으면 생략해도 됩니다. 하지만 보통의 경우는 있는 것이 훨씬 도움이 되는 경우가 많습니다.특히 '개발 편의성'은 고려 대상이 아닙니다.우리는 우리가 편하게 만들 수 있는 프로그램을 만드는 것이 아니라. 사용자가 편하게 쓸 수 있는 프로그램을 만드는 것이 우리 직업이 해야 하는 일 입니다.

마구마구 · Answer

써요. 중요성 떨어지는 프로젝트 할 때는 귀찮아서 안 하는데도 있긴 해요. 중복이 많은 협업을 하는데 협업 관리가 제대로 안 되는 곳도 싸우다가 그냥 안 하는데도 있었고. 설계가 도메인 별로 매우 독립적인 파편화, 분할화 되어 있는 경우는 안 쓰는 경우가 많고. MSA 같은 거요. 엔터티 성격에 따라도 다르고.

장독깨기 · Answer

안 쓰는 회사도 있습니다. 일반적인가? 글쎄요. ㅎ성능 문제 거의 없습니다. 어플리케이션에서 유효성 검사 다 못 해요.불편하니까 부모 테이블에 없는 데이터를 자식 테이블에 넣어도 됩니까. 자식 테이블에 데이터가 남아 있는데, 부모 테이블 삭제하면 됩니까. 안 되겠죠.외래키 없는 시스템 많이 봤습니다. 전부 데이터 다 엉망이에요.어플리케이션에서 유효성 검사 다하면, 어짜피 외래키 때문에 불편할 일 없습니다.이게 안 되니까, 자꾸 제약에 걸려서 불편하다 하는거죠. 이러면 안 됩니다. ㅎ고민하지 말고, 쓰세요. : )

캐티 · Answer

무결성이 중요하다 이럼 사용하여야 하게쩌. 외래키는 정의하는 거이고 형식만 갖추고 칼럼 네이밍으로 이케이케 하여도 되어서 정답이 없쩌.성능 문제 .. 컴퓨터는 완전무결 무결성이 보장되는거 아니어서 일반적으로 비싼 기능에는 외래키를 사용하빈다. 고액에 돈이 이동하거나 .. 이럼 정도가 심하다 싶을 정도로 설계를 하는 거여요.위에 일반적인거는 아니어서 무시하여도 선방이빈다.

길잃은유령개 · Answer

외래키로 쓰려는 테이블의 성격이나 비지니스 로직에 따라서 다른거같습니다.

Bale K · Answer

으음... 제가 대규모의 DBA 분들이나 다른 분들처럼 많이 경험한 건 아닙니다만..DB 무결성은 정말 중요하다고 생각해요그리고 다른건 몰라도 DB만은 타협하지 않습니다 😅

인간지능_ · Answer

📊 참고: 국내외 실무 사례쿠팡, 토스, 배달의민족 등 대형 시스템은 대부분 “FK 일부만 사용”하거나 “코드 레벨에서 보장”.JetBrains 개발자 설문 2023에서도, ORM 사용자의 41%는 DB 수준 FK를 일부러 생략한다고 답함.Amazon CTO인 Werner Vogels도 “강한 일관성보다 고가용성과 분산성을 우선시하는 시스템에서는 FK 제약조건을 피해 간다”고 언급.

코딩하는 두루미 · Answer

설계가 완벽하게 되어있고, 추후 변경점이 생기더라도 FK에 의한 타격은 받지 않도록 되어있다면쓰셔도 괜찮습니다.남이 설계한 테이블에 보통은 잘 걸지 않아요. 설계 초기에 고려해야할 부분입니다

xml개발자 · Answer

fk 안씁니다.데이터 변경이 일어날때마다 DB는 fk 제약조건 확인하는데... 그게 데이터가 쌓일수록, 트랜잭션이 많을수록 성능에 악영향을 미칩니다.

snow.net · Answer

다단계 외래키 구조를 쓰면 구조변경사항에 대처하기가 좀 힘들긴해요. 다단계 외래키 사용은 쿼리성능에도 좋지않고. 설계를 잘못하면 순환참조 문제가 발생하기 너무 쉬워서 한단계 정도만 하는게 좋아요. 그래서 말하신대로 복잡한 시스템에선 단순 id값만 가지고 별도로 조회해서 사용하는 구조로 짜기도 해요 대신 id를 저장한 컬럼은 인덱싱을 생성해서 빠르게 조회하는걸 최대한 활용해요.

kmksk · Answer

라이브 서비스에서 실시간 alter 가 가능할 정도의 규모라면.. 사실상 스키마 설계가 의미가 없어요.. 그냥 mongo 같은거 써도 무관..rdb 쓰는 이유가 관계 설정인데.. 사실상 실무에서 접하기 힘들어요.. 졸라큰 회사나 졸라큰 데이터 다루는게 아니면..정규화 안하면 데이터 운영이 점점 힘들어지는 시점이 오면 그때 느껴질거에요..개발자가 직접 디비 설계하고 테이블 변경하는 회사라면 사실상 안쓴다고 보면되요.. 사실 DBA 있을 정도의 회사 아니면 정규화 잘 안한다고 보면 되고, 한국 실정에 제대로 정규화 하는 회사는 드물거 같아요.

초무쿤 · Answer

FK는 논리적으로는 관리를 하고물리적으로는 생성을 않하는 편이긴 합니다.물론 프로젝트 성격, 어플리케이션유형, DBA성향 따라 다른데...전 비지니스 응용프로그램 실무에서는 FK를 잡는걸 본적이 없는거 같네용. (논리적으로는 당연히 관리 하는게 맞고요. 그냥 일반 어플리케이션이면 데이터관리가 뭐 따로 필요없으니 그냥 잡는 편이구요.)

namoda · Answer

써요. 다만 물리적으로는 안쓰고 논리적으로만 쓰고 있네요

db 외래키 실무에서 안쓰나요

15개의 답변

기술 목록