|
저도 고수가 아니고 경험도 별로 없습니다.
저도 개발 초기에 님과 같은 경험을 많이 했었죠.
즉, "정규화 등의 이론에 규합, 관리의 편리성" V.S "속도, 자료의 중복"의 문제였습니다.
결론은 '자료가 중복되더라도, 가능하면 JOIN을 피하는 것이 좋다'였습니다.. 물론 다른 의견을 내시는 분들이 있겠지만, 정규화를 통해서 DB Design을 이론에 맞게 디자인 하는 경우 JOIN을 너무 많이 하게 되어서 속도가 너무 많이 느려지게 됩니다.
1만 개의 레코드를 가진 3 개의 테이블만 조인하게 되더라도, 10,000 * 10,000 * 10,000 개의 레코드를 검색하게 되죠.. 이때는 아무리 Index를 잘 쓰고 하드웨어가 좋아도 속도가 엄청 느려지게 됩니다.
인덱스를 쓰기 어려운 상황도 있고 말이죠.
반대로 조금만 정규화를 벗어나게 되면, 속도를 엄청 나게 향상 시킬 수 있죠. 물론 관리나 코딩이 조금 어려워지지만 말입니다.
따라서 시스템의 성격과 데이터의 성격에 따라서 둘을 절충하여 사용하는 것이 좋습니다.
그럼. 이만.
-- 김재성 님이 쓰신 글:
>> 안녕들 하세요..
>>
>> 고수님들,, 특히 DB design에 고수이신 여러님들께 질문 드립니다.
>> 다소 내용이 길지도 모르겠으나.. 꼭 좀 읽어 보시고,, 답변 부탁드립니다.
>>
>>
>> 다음과 같이 3개의 테이블이 있다고 할 때...
>>
>> (고객) (계열[VISA/MASTER]) (카드번호)
>>
>> 조건: 1명의 고객은 VISA카드를 여러장 가질 수도 있고,
>> 또 MASTER카드도 여러장 가질 수 있다.
>>
>> 따라서 관계는 고객:계열 = 1:2
>> 계열:카드 = 1:N
>>
>> 이렇게 설계가 되어있는데요...
>>
>> 그런데 문제는 현재 설계되어있는 테이블이 중복된 컬럼이 많다는 겁니다.
>> 이를테면,, 카드소유자 성명이 고객테이블에도 있고, 계열테이블에도, 또
>> 카드테이블에도 있습니다. 물론 컬럼이 중복되서는 안될테니만...
>> 이유는 간단합니다. 만약 특정한 카드번호를 이용해 그 카드의 소유자
>> 이름을 알고 싶다면 굳이 JOIN을 하지않고 그냥 카드테이블만 읽어서
>> 이름을 찾겠다 이거죠.
>>
>> 그도 그럴것이 각각의 테이블의 크기가 몇 백만건 정도 된다면
>> 이름 하나를 찾기 위해서 3개의 테입블을 JOIN해야 하는가라는
>> 문제에 부딛히게 되거든요.. (정규화 논리상 이름은 고객테이블에만
>> 있어햐 한다는 조건하에...)
>>
>>
>> 그럼,, 질문 드리겠습니다.
>> 과연 이름이라는 컬럼은 고객테이블에만 있어야 하고 항상 JOIN을
>> 통해서 찾아야 한다. (=중복을 없애야 한다.) 라고 했을 때
>> 시간과 서버의 부하가 많이 갈까요? JOIN땜에??
>>
>> 아니면,, 트리거를 이용해 성명이 바뀌면 다른 테이블의 성명컬럼도
>> 바꿔주는 방법을 이용해서라도 그냥 각각의 테이블에 모두 갖고 있어
>> 굳이 JOIN을 통하지 않고라도 쉽게 찾는다...
>>
>> 이 두가지 중 어떤것이 옳고 타당할런지요..
>>
>> 고수님들의 답변 부탁드립니다...
>>
>>
>> 참고로,, 현재 저희 회사에서는요 ....
>> 그냥 각각의 테이블에 이름을 두고,, application에서 이름변경 등의 거래가 들어오면 모든 테이블의 성명컬럼을 모두 바꿔준다.
>> =(모든 데이터 정당성은 프로그래머가 책임진다)
>> 뭐 이런 식으로 되어있거든요.
>>
>> 그래서 이번에 싹 뜯어 고치고 설계부터 다시 하는데
>> 이 부분에서 선배(파일시스템에 익숙해 있는)와 의견 충돌이 있어서요...
>>
>> 저는 1번 의견이고, 선배는 3번 내지는 2번 의견이죠..
>>
>> 긴 글 읽어 주셔서 감사하고요.. 답변 부탁드립니다...
|
