봄꾸
1k
2020-09-03 11:14:00 작성 2020-09-03 11:32:30 수정됨
8
269

DB 개판으로 쓰는게 맞는건지 모르겠습니다.


일하는 곳 대부분이 DB 보면 1차 정규화 레벨부터 깨져 있고 제약 조건도 PK 빼고는 아무것도 안걸려 있는 상태에서 테이블 산출물은 최신화도 안되있어서 쿼리 보면서 테이블 관계 파악하고 있는데...

그거 관련해서 DB 정규화랑 제약조건이 안걸려 있어서 파악하는데 시간이 좀 걸린다고 말씀을 드리니 같이 일하시는 분이 "그런거 걸려있으면 사용하기 불편하다" 라고 대답하셨는데...

예를 들어 oauth 로그인 시 client 정보 테이블에서 grant_type,  scope 컬럼 등 토큰 인증 시 엑세스가 많이 일어나는 테이블에서 조인 부하를 줄이기 위해서 예외적으로 1:N 테이블 매핑 안하고 구분자로 넣어 원자 값으로 안넣는 경우는 봤지만... 아무 이유도 없이 개판으로 짜는 테이블 설계는 이해가 안됩니다.

제가 잘못 알고 있는건가요..? 

0
  • 답변 8

  • basscraft
    2k
    2020-09-03 11:23:32

    저도 개발자 이지만

    DBA와 항상 부딧히는 포인트 인것 같습니다.


    실제 개발자가 하는 일의 근본은 자연의 정보를 받아서 시스템에서 유의미한 데이터로 저장하고

    그것을 사람이 알아보기 편하게 표출 시키는 것을 자동화 하는 일입니다.


    경험이 많아 지고 시스템이 커지고 데이터가 쌓일수록 DBA의 중요성을 절실히 느끼지만

    대부분 프로잭트에서는 시니어 개발자가 DBA를 겸하고 있는 경우가 많습니다.


    큰 프로잭트에 가면 학문적으로 DB를 공부한 DBA들과 부딧히는 경우가 많은데

    실제는 그들의 말이 맞다고 봐야겠죠.

    그동안 개발자의 무지에 의해, 귀찮아서, 관습적으로 했던 일들이

    나중에 데이터가 쌓이게 되면 매우 불편하거나 시스템을 느리게 하는 근본적인 원인이 되고, 심지어 데이터를 정규화 해서 복구가 불가능 한 상태가 되는 경우가 많더라구요.

    그때가서 기업은 그것을 해결하이 위해 많은 비용을 지출하는 경향이 있는 것 같습니다.


    기본적으로 생각하시는 것이 맞다고  전적으로 동의 합니다.

  • 봄꾸
    1k
    2020-09-03 11:28:57

    basscraft

    소중한 의견 감사합니다. 

  • John Suhr
    3k
    2020-09-03 12:45:16

    DB null 제약, FK 제약, UNIQUE 제약 아무것도 안 걸고 쓰는 사람 봤습니다. 검증 코드가 매우매우 길어져 코드가 아주 더러워진 기억이 있네요.. DB에 맘대로 값 넣고 나한테 안된다고 머라하시던 팀장님...

  • 엡실론
    1k
    2020-09-03 15:07:18

    fk 제약에 대해서는 https://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys 를 참조하세요.

    non null 제약도 운영중에 칼럼을 추가하다 보면 어쩔수 없는 경우도 있고, unit testing 같은 경우 필요도 없는 데이터를 넣어야 한다는 문제도 있습니다.

    그리고 fk, non null, unique 제약만 가지고 data integrity를 충분히 만족시킬 수 없고, 비지니스 로직으로만 표현 가능한 제약이 많다는 점 등으로 디비 제약을 회의적으로 보는 의견도 있습니다.

    하지만 문서화를 제대로 하지 않는 곳에서는 저런 제약들이 그나마 시스템을 이해할 수 있는 마지막 수단이 되기도 하죠.

    제약을 쓴다고 무조건 좋은것도 아니고, 안쓴다고 무조건 나쁜것도 아닙니다. 장단을 고려해서 팀에 맞는 방향으로 가면 됩니다.

  • kkey21a
    4k
    2020-09-03 15:51:42

    저희는 업무 특성상 재작업이 많아서 DB FK를 거의 사용하지 않는 편입니다.


    FK 제약을 무조건 해야하는 것 보다 상황에 맞게 모델링하면 된다고 생각합니다.

  • 봄꾸
    1k
    2020-09-03 15:53:51 작성 2020-09-03 15:54:15 수정됨

    엡실론

    kkey21a

    의견 감사합니다. 저도 개발하면서 FK 를 반드시 걸어야 한다는 생각은 없지만

    산출물이 없거나 정확하지 않는 경우 빠른 시간에 파악하기에는 조건들이 걸려있고 조건을 토대로 툴로 ERD를 뽑아내서 파악하는게 좋다고 생각하는데.. 조건이 없으면 ERD가 바로 안그려지고 쿼리로 일일이 확인해야 하는 점이 아쉽더라구요



  • kkey21a
    4k
    2020-09-03 16:10:27 작성 2020-09-03 16:11:45 수정됨

    봄꾸//

    저도 처음 배울때는 ERD 만 있으면, 업무 몰라도 개발하는데는 문제 없어! 라고 생각하지만,

    (여기 처음와서 욕 엄청했었는데, 이제 머릿속에 릴레이션이 있다보닌깐 그냥 그러려니 합니다.)


    근데 저희쪽 업무는 실상은 ERD가 없거나 존재하긴 하는데, 정확한 릴레이션 표기 된 ERD는 하나도 없더라구요. 애시당초 설계 자체를 도메인 지식이 없으면 못하는데, 이 분이 IT지식이 무지하거나 IT지식을 중요치 않게 생각한다면 이런 경우는 크게 특이한 경우도 아니지 않을까 생각합니다.

    (이러닌깐 경력자만 뽑나봅니다.)


    마지막으로 외래키는 대량데이터 배치 처리할때, 여러므로 불편한것도 있고 퍼포먼스 문제도 있어서 꼭 필요한 경우 아니면 안쓰게 되더군요. 

    다만, 화면 처리에서는 로직으로 처리해주는 형태로 하고있습니다.

  • 봄꾸
    1k
    2020-09-03 16:31:51

    kkey21a

    말씀하신 부분 동의합니다. 하지만 데이터 무결성 깨져있는 경우를 너무 많이 봐서 필요하다고 생각합니다.

    애플리케이션단에서 처리를 잘해놔도 깨지는 경우가 많아서요..

  • 로그인을 하시면 답변 을 등록할 수 있습니다.