database.sarang.net
UserID
Passwd
Database
ㆍDBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DBMS Q&A 119 게시물 읽기
No. 119
Re: Re: DB 디자인시 데이터 중복과, 편리성의 문제
작성자
jongwoo.han
작성일
2001-12-03 13:01
조회수
14,144

아시다시피 join은 값비싼 오퍼레이션입니다. 그렇지만 아래 같은 경우에는 굳이 피할 필요는 없는데, 왜냐하면 그런 낭비를 피하기 위하여 질의 최적화기가 내장되어 있기 때문입니다. 옵티마이저(최적화기)는 중복시켜서 바로 검색하는것 보다 좋은 결과는 내주지 않습니다. 그러나 아래같은 경우에는 옵티마이저가 여러가지 가능성을 상정한다음에 조건검색(고객이름) 을 먼저 찾은다음 해당 외연 키를 가지고 다른 테이블과 조인하므로, 10만건 * 10만건이 있다고 10만*10만번 조인시키고 나서 검색하지는 않습니다. 특히 value로 찾는 조건이 있는 경우에는 목적 테이블에서 1건만 나오면 1건에 대해서 조인을 하므로 중복시킬 필요는 거의 없습니다. 즉 조건이 명확할수록 3번의 B트리 검색에 가까와지는것입니다. 물론, 그런 효과를 얻기 위해서는 참조되는 컬럼은 인덱스되어 있어야 합니다.

 

 

-- 허정수 님이 쓰신 글:

>> 저도 고수가 아니고 경험도 별로 없습니다.

>> 저도 개발 초기에 님과 같은 경험을 많이 했었죠.

>>

>> 즉, "정규화 등의 이론에 규합, 관리의 편리성" 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번 의견이죠..

>> >>

>> >> 긴 글 읽어 주셔서 감사하고요.. 답변 부탁드립니다...

[Top]
No.
제목
작성자
작성일
조회
118눈물로 호소합니다...ㅠ.ㅠ
남규한
2001-12-03
14482
163┕>Re: 눈물로 호소합니다...ㅠ.ㅠ
김동아
2001-12-12 11:50:14
12823
115데이터베이스 관련 저널 URL
정재익
2001-12-03
13336
105관계에서요 키 설정하는 부분이 이상해서요. [2]
언제나
2001-12-02
15820
103DB 디자인시 데이터 중복과, 편리성의 문제 [2]
김재성
2001-11-30
14300
106┕>Re: DB 디자인시 데이터 중복과, 편리성의 문제
허정수
2001-12-02 14:55:12
13973
119 ┕>Re: Re: DB 디자인시 데이터 중복과, 편리성의 문제
jongwoo.han
2001-12-03 13:01:42
14144
102ER-WIN에 대해 아시는 분좀 봐주세요.
이종성
2001-11-30
13107
101오라클,mssql,mysql 에 대한 성능비교?? [2]
김명현
2001-11-29
17029
95흑 정말 모르겠습니다. 고수님들께~!! [1]
후니
2001-11-27
10405
96┕>Re: 흑 정말 모르겠습니다. 고수님들께~!!
허정수
2001-11-27 22:51:06
10759
97 ┕>Re: Re: 허정수님 답변이 ^^?
후니
2001-11-28 09:08:05
11081
99┕>Re: 흑 정말 모르겠습니다. 고수님들께~!!
김동아
2001-11-29 00:22:30
10788
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.026초, 이곳 서비스는
	PostgreSQL v16.4로 자료를 관리합니다