답변에 앞서, 커뮤 글은 여러 명에게 검증받은 공식 문서가 아니라서 틀렸을 가능성이 상대적으로 높다.
거기다 사람 말이라는 건 언제나 컨텍스트를 기반으로 하기 때문에 오해의 여지가 있을 수밖에 없지.
가장 좋은 건 스스로 판단하는 거야.
예를 들어 A와 B의 말이 다르면 검증을 해봐야 해. A의 말을 인터넷에 검색해봤더니 외국 개발자 커뮤니티에서도 A 말이 맞다고 하네? 그런데 B는 공신력 있는 타이틀을 가지고 있네?
이런 경우에는 십중팔구 네가 B의 말을 잘못 알아들었거나, B가 뭔가를 오해했거나 둘 중 하나일 거야.
그런데 너는 그걸 판단할 능력이 없잖아? 그럼 차선책을 선택해야지.
차선책은 또 다른 사람에게 검증을 요청하는 거야. 백갤 같은 데다 질문글을 올리는 거지.
그럼 최소한 네가 얻은 정보에 대한 상세한 정보를 제공해줘야 해. 글을 복사해서 주든, 링크를 전달하든 말이야.
네가 전달한 질문이 어떻게 오염됐는지 검증자가 어떻게 알겠냐?
질문
근데 RDB에서 FK가 핵심이라고 하던디요제생각은 아니고 개발커뮤에서 줏어들은건데
rdb 쓰면서 테이블 쪼개놓고 fk 안걸꺼면 뭣하러 rdb 쓰는지 이해를 못하겠다 이런 의견들이 많던데
dba분들도 fk 못걸게 하나요?
답변
질문만 봐서는 질문자가 본게 논리적인 FK에 대한 내용인지, 물리적인 FK 제약조건에 대한 내용인지 알수가 없음
뉴비들이 종종 하는 오해라서 더더욱 그러함
논리적인 FK에 대한 내용이면 무분별한 반정규화가 일어난 케이스를 말한걸거고, 이런 경우에는 RDB 쓸 필요 없는게 맞아
물리적인 FK 제약조건에 대한 내용이면 잘못된 글을 본거야
특정 데이터가 변경됐을 때, 관련 테이블 수십개의 수천만건의 row에 변경된 정보가 적용돼야하는 상황을 가정해보자, NoSQL이면 어떻게 해야할까? 이벤트 드리븐으로 관련 모든 테이블들이 업데이트 되는 시스템을 구축해놔야하겠지?
그게 싫으면 관련 테이블을 분리하고 추가 쿼리 날리는 방법을 쓸수도 있겠지, 근데 그런식으로 테이블이 하나둘씩 늘어나면?
그게 싫으면 관련 테이블을 분리하고 추가 쿼리 날리는 방법을 쓸수도 있겠지, 근데 그런식으로 테이블이 하나둘씩 늘어나면?
반면에 RDB를 쓰면 특정 데이터를 별도 테이블로 분리해놓고, 필요할때 join하면 땡이야
join 테이블 좀 늘어나도 어느정도 선까지는 성능에 크게 문제 없어
트랜잭션은 어떨까? RDB급의 트랜잭션을 지원하는 DB가 있나? 있다 하더라도 join도 해주고 트랜잭션도 해주나? 인덱스 유연하게 걸 수 있나?
집계 쿼리 성능이 RDB 처럼 나와주나? 소규모~중규모 단순 쿼리 성능은 RDB 처럼 나와주나?
이 모든걸 한데 스까서 국밥성능 내주는데, 고작 FK 제약조건 안쓴다고 RDB 박탈당해? mysql버려? postgresql 버려?
미친소리 하지 말라 이거야
이 모든걸 한데 스까서 국밥성능 내주는데, 고작 FK 제약조건 안쓴다고 RDB 박탈당해? mysql버려? postgresql 버려?
미친소리 하지 말라 이거야
제약조건 안쓰면 데이터 무조건 잘못돼? NoSQL 쓰면 데이터 무결성 보장 안돼도 된대? 기술을 쓸때 가장 중요한게 현실에 직접적인 이득이 있느냐인데, 이론에만 빠지면 아가리파이터, 오버엔지니어 되는거야
물론 대규모로 가면 RDB 쓸 이유가 별로 없는건 사실이야, 근데 세상에 서비스가 대규모 뿐인가?
그리고 기술의 쓸모에 대해 이야기하려면 상황부터 정의하는게 정상 아닌가?
무결성이 생각보다 안중요한가보네 학식으로는 내용이 낯설다 - dc App
중요하지 - dc App
중요하긴 한데, 일반적인 경우에는 그 정도로 큰 대가를 지불할 정도로 중요한건 아니야 무결성은 어플리케이션 로직과 트랜잭션으로도 어느정도 제공할 수 있거든 만약 무결성이 극도로 중요한 서비스라면 FK 제약조건 걸어야지 본문에도 써놨지만 기술의 쓸모는 상황이 결정하는거야
내용이 낯선 이유는 니가 RDB 공부만 했기 때문이야 모든 학문들이 자기들이 추구하는 가치가 세상에서 제일 중요하다고 함 우리는 그 학문들을 엮어서 결과물을 만들어내야하는 사람이고 객체지향 공부했다고 모든 코드를 객체지향적으로 짜는게 맞다고 생각하냐?
이건 대기형이 써서 글삭될 위험은 없겠군
만약 틀렸을시 바로 삭튀함
이 댓글은 게시물 작성자가 삭제하였습니다.
참 글 잘적네 글 많이 적다보니 는거여? - dc App
서문은 챗티로 다듬음ㅋㅋ
ddb같은건 인덱스 한번 바꾸려면 테이블 갈아엎어야해서 rdb가 이럴땐 편하긴 함
인덱스+세션기반 트랜젝션이 사기템임
rdb는 옵티마이저랑 인덱스 아키텍처가 핵심인듯 특히 데이터가 암만 많아져도 모든 데이터에 대해 동일한 접근비용을 가지는 인덱스 아키텍처가 야무지다고 할 수 있다 - dc App
마소다닌다고하는 사람의 말도 결국엔 논리fk의 중요성을 강조하고있는 내용인데, 결론을 물리fk를 걸어야한다고 내버리면 안된다는거지.. 물리fk는 현실적으로 득보다 실이 많은 제약조건임
애초에 마소 다닌다고 다 맞는 말만 하는게 아님 누가 말하든 필터링 없이 받아들이는건 바보나 하는 짓이지
그리고 그 사람 왠지 물리 fk 말하는거같던데.. 글 내용만 보면 논리 fk 말하는 것 같긴 한데, 논리 fk는 그사람이 언급할만한 가치가 없음
오
FK 아니어도 RDB가 가지는 메리트가 충분히 많음.. 오히려 그런 수준에선 FK가 은근히 걸리적거릴때도 많고..