기술 부족이죠.

한국의  시스틈은 대충대충 땜빵,땜빵 전문가 배제... 최저가 입찰, 업체교체...

등... 합리적이지 못한 시스템이 대부분이죠.

그러다 보니... 외래키,기본키는 어느정도 관리가 되고, 대용량뿐 아니라 소규모에서도 다루는 기술이 필요한데..

이게 적용되어 있으면... 분석하고 제데로 사용하는데.. 비용이 발생하니까.. 그냥 빼고 하는게 아닐까요?

pk,fk가 문제라면.. 그건 disable시키고 작업하면 됩니다.

그 과정 자체가 번잡하니가... 관리가 안되니까... 다 빼는 것이죠.

즉 개판입니다.

합당한 이유는 개판인 환경내에서...

관리가 안되니까.. 빼고.. 개판에서 개짓 하는 것이라고 생각합니다.

그런 얘기를...제 생각은 좀 다릅니다...^^;

1. 일단 PK는 없으면 데이터의 무결성을 정확히 보장하지 못합니다.

2. PK = 유니크 + Not Null입니다. 유니크로만 관리하면 Not Null에 대한 관리가 안될 수 있어 Primary Key 컬럼들에 Null값이 들어가버리는 실로 엄청난 재앙을 초래할 수 있습니다...해서 PK는 반드시 설계상에 있습니다...PK 없는데가 비정상이란 얘깁니다...;

3. FK와 PK관계에 대해 아신다면 큰 시스템일 수록 FK를 안 쓰게되는 어쩔 수 없는 경우가 좀 있습니다.
Master의 PK에 없는 Key를 가진 자료들은 FK쪽 테이블에 입력조차 안된다는 것을 아실 것 입니다.

FK 관리가 어려워서가 아니고 실무에서 시스템이 클 수록...;

프로젝트에 의한 Data Mig.의 비순서적 처리가능,
=> 테이블 십만개 정도에 FK걸어놓고 Mig 할 테이블들의 순서를 ERD놓고 순서대로 찾아보세요...못 할껄요...^^; 

개발이전 과거 이력들에 대한 Data RI의 Mismatch 가능성,
=> 그럼 오류나는 과거 이력들은 버릴까요?

타 시스템과의 빈번한 Data Interface 시 상호코드간의 불일치성 등
=> 신규코드 입력해서 송신측에서 데이터를 다시 말아주기 전엔 우리쪽 업무는 마비 또는 오류나야 하나요?

실무에서의 FK를 잡을 수 없는 다양한 상황에 대해 오류데이터의 오류/누락 보다는 입력/보존이 더 큰 이슈가 되기 때문입니다.

4. 이것도 중요한 이유 중 하나, FK선언 시 Delete Cascade 라는 걸 아시나요?
이 옵션 누군가 개발자가 실수로 잘못 걸어놓으면 삭제하나 잘못하면 관련된 데이터들이 순식간에 DB에서 전부 사라집니다.
즉, 아무도 책임질 수 없는 사태가 일어난다는 말이죠.

30초 정도만 생각해도 절대 기술부족은 아닙니다.
(PK/FK가 뭐가 어려운 개념이라고요...DB개념의 기초중에 기초입니다...^^)...
실제 대용량 프로젝트에는 FK개념 정도는 비교도 안되게 더욱 심오하고 엄청난 컨셉/기술들이 적용되어 돌아가고 있습니다...^^;

로그인을 깜박하고 적었군요...;

익명으로 남기면 책임감(?)없는 글이 될까봐 로그인 후 사족을 추가합니다...^^;

건승하시길...수고하세요~~

글쎄요...DB 분야가 원래 정형이란게 모호한 면이 있지만...

저의 경험을 말씀드리자면 아무 이유없이 안쓰는 싸이트가 더 많다는 게

저의 생각입니다. 물론 FK를 완벽하게 구현한다는 생각은 그냥 이상적인

경우라 현실과는 괴리가 존재하지만...

PK에 대해서는 언급할 필요가 없어서 생략하게씁니다.

저는 데이타 이행 프로젝트를 다른 분들에 비해 자주 해보았지만,

사실 과거 이력들의 Miss Match도 그게 중요한 테이블(ERD상 외곽이 아니고 가운데에 주로 있는 

테이블) 이라면 이런 점도 충분히 고려해서 Cleasing을 하든가 아니면 가상의 데이타생성으로 인위적으로 피해가는 방향이 충분히 고려해야 됩니다. 여기서 과거 데이타의 Miss Match발생 또한 

대부분은 FK에 대한 경시 떄문에 발생한 결과일 겁니다.(계속 악순환인 것이죠)

물론 성시현님도 언급만 안하셨지 동의 하시지 않을까 싶네요...^^

그리고 저는 Delete Cascade는 설정을 안하는 것을 우선시 합니다.

물론 제 맘대로 만드는 제 개인 소유라면 CASCADE를 쓰겠죠...

결국 다른 DBA를 못 믿겠다는 심리가 좀 있는 셈이네요... 

어쨌든 몽땅 줄줄이 굴비처럼 사라지는 재앙을 방지하는게 낫다는 것입니다.

결국 지울려면 밑에서 부터 하나하나 지우든가 아니면 DEL_FLAG를 쓰던가 해야겠죠.

FK가 반쪽 구실만 하는 셈이지만...현실과 타협해야겠죠

그리고 FK를 무시하면 결국엔 시간이 감에 따라 점점 정보자원이 비효율적이 될 수 밖에 없습니다.

마치 물리학에서 '엔트로피는 시간이 지남에 따라 증가한다.'는 원칙이 딱 들어 맞는 경우라고

생각되네요. 특히 요즘처럼 초급DBA인 외주 SM직원이 Ad-hoc SQL로 DB작업을

한다면 정말 무슨 사고가 발생할 지는 뻔합니다. 그 후임은 그런 행동을 반복할 것이고...

이런 상황이 진행되면 초기에 개발했던 Application에서 Inner Join으로 작성한 SQL를

OUTER JOIN으로 바꾸지 않는 한 결국 화면에서 볼 수가 없게 되는 거죠...

아니면 초기부터 OUTER JOIN을 권장하든가요...^^

아뭏든 제가 볼 땐 명확한 사유가 없다면 FK는 써야 된다는게 저의 기본 생각입니다.

통신사 중에서 L모 사도 암닥스 모델 기반인데 역시 FK 안씁니다. 그에 대한 명확한 이유는

모르겠습니다.

그리고 마지막으로 제가 본 Oracle ERP HR에 제가 본 테이블은 다 PK가 있던데요...

     PS : DB 일을 하면서 점점 불가지론자가 되는 타칭 DBA가 한 글 남겨봅니다.

여러분들은 NULLS LAST, NULLS FIRST를 아시나요?

정말 아무리 전문 SQL 개발자가 아니라지만 이제까지 Java개발자중에서 

아는 분을 한 명도 못봤네요...

허긴 Outer-Join도 모르는 분도 많은데요...

...

WHERE A.SEQ = B.SEQ(+);

...

WHERE A.SEQ = B.SEQ(+)

AND   B.SEQ(+) = '2';

...

WHERE A.SEQ = B.SEQ(+)

AND   B.SEQ = '2';

요즘 전 제가 바보가 된 기분입니다.

지금까지 전 기본에 충실하게 설계해왔습니다.

데이타 마이그레이션도 외래키 끊고 피해간 적 없구요..

근데 요즘 좀 헷갈리네요...

전 주로 10억 미만의 프로젝트만 해 왔습니다.

대부분 건설 회사였구요 제 경력(14년차)에 비하면 일찍부터 PM 노릇(6년차부터)을 했구요.

전 제가 지금까지 한 프로젝트에서 단 한번도 외래키 제약을 어기고 한 적이 없습니다.

그리고 문제 없었구요...

(첨언하면 업무를 무시하고 FK가 있어야 한다는 건 아닙니다. 그러나 정책으로 FK는 없다고 가져가는가? 하는거죠...)

근데 요즘 제가 남의 프로젝트에 날일(프리로...)을 뛰게 되다 보니 좀 큰 회사랑 일을 하거든요....

그런데 저런 말을 들은겁니다...

그래서 사실은 잘 믿어지지 않아서 여쭙는 겁니다...

정말 큰 회사들은 그렇게 하나요????

(어제는 테이블 생성 스크립트를 만드는 작업을 하면서 ER-WIN에서 제네레이트 옵션을 결정하는 회의를 했는데... 저런 말을 들은 겁니다. 심지어는 check constraint도 안달아야 한다고 하더라구요... default value는 해도 된답니다.)

전 정말 현실이 궁금합니다....

정말 그렇게들 하나요?

음... 김흥수님이 아마도 이제까지 좋은 기술적환경에서 작업을 하셨나 봅니다.^^

좀 더 깊은 애기를 드리자면 제 경험에서 볼 때 DB설계, Apllication설계/개발 등등이 분업화 된 시점이 불과 10여년 정도 되가는 것같습니다. 그전에는 한 사람이 이것 저것 모두 하는 시절이 있었죠

(새삼 그떄가 그립기도 하네요...저는 96년도 부터 프리를 했습니다.)

그리고는 Web시대가 도래했죠 이떄부터 Java가 프로젝트의 메인스트림을 차지하게 되죠...

이때 각 PL들이 막강한 권한을 본의든 아니든 부여받게 됩니다. 그들은 최신 아키텍쳐와

화려한 UI, 문서로 프로젝트의 헤게모니를 장악합니다. 이 때 소수의 DBA는 그저 중앙 쯤에서

(개인적으로는 싫어하는 위치입니다.) PL들의 요청에 따라 작업하는 수동적인 자세가 됩니다.

사실 DBA라는 단어가 포괄적인 단어가 되는 시점입니다. 

이때 ERD, 테이블컬럼명세서 정도되는 빈약한 visual한 문서는 그저 Sync 작업이나 하는

개발자 배포 문서죠

Naming도 Java 냄새가 나고 FK는 논의조차 안합니다. FK 애기하면 질색을 합니다.

Check/Default도 거의 애기 꺼리가  아닙니다. 하나 예를 들면 테이블명이 이렇습니다. TBUCCOOPERBIZPERSMT 아마 이분은 오라클도 자바처럼 대소문자 구분해서 명명되는 줄 

아시나 봅니다. TbucCooperBizPersMt처럼 말이죠... 

그리고 가장 핵심인 DB설계는 화면 설계가 대치합니다. 즉 화면 하나가 엔티티 하나인 셈이죠...

물론 Visual한 화면이라는 표현양식이 효율적인 것은 사실이며, 또한 훌륭한 수단임이 분명합니다.

물론 모든 Java 개발자가 그런 건 아닙니다만, 그 분들은 DB서적보다는 Spring책 구입을 선호합니다.

그리고 본인들은 DB의 기본은 안다고 합니다만 위에 위에 제가 예를 든 SQL를 설명하면 대부분

신기해 합니다.(순간 저는 오싹하죠) 

제가 나름 단순화하여 설명한거지만 이게 요즘 SI의 현장의 한 사례입니다. 

저는 외국(주로 영어권)에서도 이런 식인지가 궁금하네요. 

PS:

Java개발자들은 Modeller를 하면 안되다는 건 절대 아닙니다. 혹시나 기분 나쁘게 받아들이셨다면

너그러이 이해해주시길 바랍니다. 참고로 저는 Java를 거의 모릅니다.^^

그러심은....

많은 곳에서 그렇게 한다는 말씀이신지...

정책적으로...

(FK는 안가져간다... 피치 못할 사정이 있는 경우 없어도 된다가 아니라...)

그런데... 제가 들은 얘기를 좀 더 해보면 이렇습니다.

제게 대용량에서는 FK 없고 심지어는 PK도 없다고 하신 분은 무려 경력이 20년이 되시는 자바세대가 아니신 분입니다.

그분 말씀에 따르면 "JAVA 개발자나 등등의 개발자는 명함도 못내민다.

대용량 디비를 쓰는 큰 업체에서는 DBA들이 정책적으로 FK는 안가져 간다...

다들 그런다... 그런걸로 봐서 아마도 한군데서 다 배워 왔나보다."

이렇게 얘기 하시거든요...

그분 말씀의 의미는 이런 정책을 퍼뜨리며 정당시하는 그런 DBA 리더들이 있다는 뉘앙스였어요...

그러니 일개 개발자인 저는 디비 좀 안다고 깝쭉대지 마라... 뭐 대충 이런 분위기였거든요...

김흥수님 //

대용량에서는 FK 없고 심지어는 PK도 없다. <==  그렇게 얘기한 분이 제정신이 아닌거겠네요...

우선적으로 PK가 없다고 한다면 정말 작은 사이트가 아니고서는 상상도 할 수 없는 일입니다.

PK없이 도대체 어떻게 Data를 관리한다는건지...

또한 FK같은 경우는 cascade문제 때문에 걸려있으면 좀 복잡한 면이 있지요.

하지만 ERD만 제대로 구성되어 있어도 그거 보고서 작업하면 문제가 없지요.

cascade에 의해 모든 data가 삭제가 되서 문제가 된다면 기본 설계 차원의 문제이구요.

결국 저런 설계 차원에서 책임 소재를 두기 싫으니까 Data의 중복을 그냥 묵과하고 싶다는

얘기밖에 되지 않습니다.

억, 수천만 단위의 row를 가지는 테이블들에서 Data duplicated문제가 불거져서 몇주간 고생한 경험이 있는데,

결국 원인은 특정 시점에 누군가가 FK constraint를 disable했던게 문제가 됐었습니다.

disable하고 자신은 data insert하고 자기 작업은 잘 ㅤㄷㅚㅆ겠지만,

몇년후에 결국 그 문제때문에 다른 사람들이 엄청 고생하게 된거지요.

프로젝트 끝나서 나갈 사람이라면 별 상관 안 할 수도 있지만 뒤에 남게 되는 사람은 고생이지요...

많은 관심에 감사드립니다...

많은 도움이 되었습니다.

조회수가 300이 넘은 것을 보면...

이 문제에 직접적으로 의견을 달지 않으신 분들도 이 문제에 상당한 관심이 있으시다는 뜻으로 보입니다.

그리고 cascade delete 에 대한 문제에 대해서도 상당한 관심이 있으신 것을 알았습니다.

이것도 좀더 논의해보면 재미있을 듯 한대요....

기회가 되면....

^^