기존에 회사에서 SI 업무를 하다가 더이상 SI업무는 안하고 있는데 SM은 계속 하는게 좋다는 방침으로.. 웹 개발을 가끔 하고 있습니다.
그런데 묘한 궁금증이 생겨났는데 웹 쪽이 전공이 아니라.. 궁금한걸 해결할 방법이 없어 질문드립니다.
기존 SI 업무를 했을 때 DB 구조를 보면 (MySQL 기준입니다.) 분명 FK, unique index가 있으면 좋은 상황인데도 사용하지 않더라고요.
웹쪽 질문으로 말씀드리는 이유는 응용 프로그램이나 다른 서버에서 사용할 프로그램을 짤 때는 분명 FK를 사용했었습니다. 그런데
웹 개발한 것들을 보면 5중 조인이 되어있는 쿼리도 있는데 인덱스는 no 필드 하나에 pk로 걸고 땡이더군요.. 이걸로 조인하는건 맞지만
fk 설정을 하면 퍼포먼스로 봐도, 편의성으로 봐도 이득 아닌가요..? 게시판 같은 페이지도 아니고 서비스 결제 관련 로직이라
실질적으로 부하를 주거나 하는 로직도 아닌데.. 오히려 관리자 페이지에서도 JOIN을 해야해서 어마무시하게 느립니다 ㅡㅡ;
1. 웹 개발의 경우 외래 키를 사용 안하는지?
2. unique key 도 사용하는 것을 보질 못했습니다. 회원 아이디의 경우 무결성이 필요하면서 index 설정하는 것이 이득이라 보이는데.. 사용하지 말아야 할 이유같은게 있는 건가요?
3. db정규화를 해야한다고 배웠는데 제가 했던 sm 업무들 대부분은 그런게 없었습니다. 웹에서 DB 정규화를 하면 안좋은 점이 있나요? 퍼포먼스로는 하락이 있을 수 있겠지만 MVC 패턴과 같이 확장성과 관리의 용이함에서 가지는 이점이 뛰어난 것 아니었나요..?
업무량을 통해 프로젝트 기간이 산출되지 않아서
설계/개발 기간이 보통 절대적으로 부족한 상황에서
DB 제약을 걸어 놓으면
개발기간안에 개발 못한다고 압력이...
DA 가 투입된 프로젝트는 정규화를 잘 수행하는 편입니다.
개발 PL 들이 설계를 하는 경우 정규화가 많이 부족한 편이죠.
퍼포먼스는 과도한 정규화만 아니면 보통 정규화 되어 있을때 더 좋게 나옵니다.(경험상)
1번하고 2번 답변 : 케이스 바이 케이스입니다.
규모가 작은 사이트나 중요도가 좀 낮거나 개발일정이 너무 촉박하거나 그런 경우는 no에만 pk걸고 나머지는 전부 어플단에서만 처리합니다.
규모가 좀 되거나 (돈값은 해야되니깐) 중요도가 너무 높은 곳은 어플단에서도 체크하지만 한치의 불량데이터도 있어서는 안되기 때문에
그런곳을 개발할땐 fk, unique 전부 다 사용합니다.
3번 : 위의 답변과 기본적으로는 같고요.
웹이라고 하여도 업무시스템같은 특정 소수 이용자 사이트는 상관이 없을수도 있지만,
불특정 다수가 겁내 많이 들어오는 사이트는 바로 그 약간의 퍼포먼스 하락을 결코 무시할 수 없게 됩니다.
극단적인 경우는 동일 데이터를 사방에 복사하기도 하고 (캐쉬효과?) 벼라별 작업을 다 합니다;;
캐쉬도 걸 수 있으면 최대한 걸고요
사용자들이 예전엔 그래도 클릭했을때 2~3초 정도는 기다렸지만 요즘엔 1초 넘어가면 화면 닫아버립니다.
애초에 느리면 고객사에서 검수를 안해주죠.
물론 저같은 경우는 제가 느린걸 너무 싫어해서 그렇게 만들지도 않지만
다른업체가 속도 문제로 검수를 못받아서 한달동안 튜닝만 주구장창 하는걸 봤습니다.
비정규화는 물론이거니와 ajax방식을 포함한 온갖 고급기법 사용해서 이쁘게 만든 UI까지 싹 바꾸면서 겨우 1초내로 진입하여 완료하더군요.
(제가 기존에 동일디비 동일 환경 동일 구성으로 0.1초내로 나오는 사이트를 미리 만들어 놓은 것 때문에 더 비교되서 그런걸지도 ㅋㅋ)
필요 있던 없던 unique key는 반드시 넣어야 합니다 (auto)
innodb의 성능에 영향이 있습니다.
join의 경우는 속도가 늦습니다.
그래서 join과 sub set operation + join 등의 방법을 적절히 섞어서 씁니다. 상황에 맞게.
경험칙이 더 큽니다.
1의경우 FK를 하지않으면 장/단점이 있습니다... FK가 없으면 DB변경이 좀더 자유로워집니다..
운영적인 측면에서 보면 FK없는게 좀더 이득일수있습니다.
FK가 제대로 걸려있는경우는 데이터 수정을 하나할려고해도 여러테이블을 전부 신경써줘야하는 경우가 생겨서요...
반대로 데이터정합성은 좀더 보장이 돼겠지요...
2의 경우는 특별한 이유가 있어서 그런건 아닌것 같네요...
프로그램적으로 중복을 막았다고해도.. 중복건을 허용하지않을것이라면 PK는 존제하는게 나아보이네요...
3의 경우도 결국 설계당시에는 정규화를 어느정도 했었지만...
운영하다보면 정규화를 하게돼면... join이 많이 사용돼고.. 불편한경우가 있어서...
아마 운영하면서 컬럼들이 늘어난경우라면.. 정규화를 안한경우도 많이 생길수있죠...
다만 얼마나 많은 수정건이 발생할지 모르는 상황이라면 않하는게 편하겠죠.
상황별로 전 그냥 트리거를 사용하거나 일정 시간별로 무결성 체크하는 부분을 넣어줍니다.
꽤 오래 이쪽일 했는데 처음에는 ASP + MSSQL로 시작해서 FK는 당연한걸로 봤지만 시간이 지날수록 않하게 되더군요
2. 상황별로 틀리겠죠. 어디서는 ID를 unique를 쓰겠지만 생각을 좀 더 달리한다면 user_no를 unique 형태로 해놓고 ID는 그냥 따라다니는 형태로 만들기도 하거든요
3. 문서화가 중요한 이유겠죠. 사전에 문서화되지 않은 개발 사이트는 정규화를 제대로 하지 않는 경우가 많습니다.
말씀하신 내용은 개발단계에선 그럭저럭 넘어갈만한데
나~~~중에 data 가 누적되고 DB가 거대화 되면서 장애를 일으키는 포인트가 되는 사항들이죠 모,,,
쿼리튜닝과 더불어 index 적절히 걸어주는 것도 속도에 중요하더군요.