상세한 답변 감사합니다...

제가 논지를 정확히 이해했는지 확인을 부탁 드립니다.

1. PK 안가져가는 곳은 못 봤다.

2. FK가 없는 경우는 많은 경우 과거자료 때문이며 정책적으로 그러는(FK 가져가지 말라는 정책)

  경우는 잘 보지 못했다.

3. 데이타의 정합성의 문제는 단순히 FK 만의 문제는 아니며 그 보다 더 심오한 품질검사를 거친다.

4. 가능한 신규 프로젝트는 DA 관점을 준수하는 것이 합당하다.

대략 이런 의미신것 같은데...

맞으신가요?

그리고 전 성시현님께서 FK 없는 상황을 옹호하신다고 생각하 적은 없습니다...

단지 경험이 풍부하신 것 같아서 여쭤본것입니다.

많은 도움이 되었습니다.

제가 오해한 부분이 있다면 지적을 해주시기 바랍니다.

^^

김흥수님이 재미있는 주제를 던지셨네요.

저의 얄팍한 경험을 말씀드리자면, 관성이라고 봅니다. 해당 업계에서 통상적으로 사용되던 정책이 있으면 그걸 쉽게 바꾸고 싶어하지 않고 실상 바꾸기 쉽지도 않습니다.

FK같은 경우에는 정말 여러가지 이유로 적용이 쉽지 않은 사이트를 많이 만나게 되더군요, 수많은 히스토리와 의례히 FK를 사용하지 않아온 해당 업계 개발자들의 관성들도 만나게 되지만, 성시현님도 말씀하신 내용과 겹치기도 하는데 고객사와 고객사를 둘러싼 무수한 협업관계의 조직들간의 정치적 관계도 무시할 수가 없더군요. 

예를 들자면 데이터를 주시는것만으로도 감지덕지 해야 하는 상황이 닥치구요.

앞서 게시하신 게시물에도 재미있는 경험, 의견이 많이 있던데 길지 않은 글을 정리해보자면 요렇습니다.

1. 해당 업계에서 통상적으로 사용되던 정책이 있으면 쉽게 바꾸려고 하지 않는다.

2. 고객사의 이해와 고객사를 둘러싼 협업관계 조직들과의 정치적 관계가 시스템의 정상적 규칙을 위배하는 경우가 발생한다.

3. 시스템의 유연성이란 개발 편의성으로 해석되는 경우가 많다.

시스템의 유연성이란 개발편의성으로 해석되는 경우가 많다.!!!

이 말씀이 가슴을 후벼파는군요....

ㅋㅋ

저 오늘 테스트 데이타 만들다가 실수했습니다....

FK 없는 환경에서 일한지 얼마 되지 않아 바로 실수하는군요....