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 662 게시물 읽기
No. 662
제목 : 테이블 설계: 참조하는 방식 두가지 조언구함
작성자
스키마
작성일
2003-01-08 17:14
조회수
6,931

테이블 설계를 하는도중 이런 궁굼증이 생겼습니다.

현재 일반적으로 아무의심도없이 많이 사용되고있는 "방법B"를 왜 그렇케

많이 사용하는지에 대해 의견을 주시면 감사하겠습니다.

 

 

 

*************************** "방법A" ****************************

 

테이블 : MEMBER_NAME

==========================================

IDX(PK) NAME

==========================================

1 김또깡

2 하야시

 

 

테이블 : MEMBER_INFO

==========================================

IDX SEQ 평가 (* IDX + SEQ가 PK)

==========================================

1 1 바보김또깡

1 2 멋진사람입니다.

1 3 시대의풍운아

2 1 쪽바리나쁜놈!!

2 2 암턴멋져!!

2 3 바보아닐까?

 

"방법A" 에선 IDX와 SEQ를 합쳐서 기본키로 잡는겁니다.

그리고 MEMBER_NAME 테이블의 IDX를 MEMBER_INFO 테이블의 IDX가 참조하는겁니다.

 

 

 

 

*************************** "방법B" ****************************

 

테이블 : MEMBER_NAME

==========================================

IDX(PK) NAME

==========================================

1 김또깡

2 하야시

 

테이블 : MEMBER_INFO

==========================================

IDX(PK) M_IDX 평가

==========================================

1 1 바보김또깡

2 1 멋진사람입니다.

3 1 시대의풍운아

4 2 쪽바리나쁜놈!!

5 2 암턴멋져!!

6 2 바보아닐까?

 

"방법B" 에선 MEMBER_INFO 테이블의 IDX 한가지만을 기본키로 잡았으며,

그것은 AUTO_INCREMENT 속성을 가지기때문에 계속 증가합니다.

M_IDX는 MEMBER_NAME 테이블의 IDX를 참조하는 경우입니다.

이 글에 대한 댓글이 총 2건 있습니다.

개념적으로 설명하자면...

 

MEMBER_INFO 는 약엔티티 집합이며...

 

물론 약엔티티에 대한 개념은 학자마다 틀리지만..

 

저는 지금 상황을 약엔티티 집합으로 보고 있습니다.

 

속성으로 볼때는 MEMBER_INFO자체가 다중값 속성

 

입니다. 즉, MEMBER_INFO라는 자체가 다중값 속성

 

에 대한 문제를 해결한 것입니다..

 

어쨌든지...방법A, 방법B가 설계속성을 포함하고 있는

 

것은 사실입니다.

 

방법들에 대한 글을 볼때는 단순히 부모 엔티티에

 

대한 여러가지 설명으로 MEMBER_INFO가 들어간

 

것입니다..

 

만약 방법A의 SEQ가 어떤 의미를 지니고 있다면

 

필요하겠지만 단순한 숫자를 의미하는 것이면

 

필요없는 데이터가 저장되는 격입니다....

 

물론....게시판 같은 것에서는 게시판의 특성상

 

방법A가 되든 방법B가 되든 필요하겠지만요...

 

기본적으로는 두가지다 Redundant가 붙은거죠..

 

어쨌든 두가지는 한가지 상황에만 적용되는 솔류션

 

이 되는 검돠...

 

어쨌든...

 

여러가지 방법이 있다면 어떤 방법을 선택할 것인가에

 

대한 기준은 '데이터베이스의 정의'에 맞는가를 따져

 

보는 것이 바람직할껌돠...

야시님이 2003-01-08 20:23에 작성한 댓글입니다.

그냥 지나치다가 덧붙여 노파심에나마 이야기 하자면..

 

야시님께서 잘 설명해 주셨듯이...

------------------

개념적으로 설명하자면...

MEMBER_INFO 는 약엔티티 집합이며...

물론 약엔티티에 대한 개념은 학자마다 틀리지만..

저는 지금 상황을 약엔티티 집합으로 보고 있습니다.

속성으로 볼때는 MEMBER_INFO자체가 다중값 속성

입니다. 즉, MEMBER_INFO라는 자체가 다중값 속성

에 대한 문제를 해결한 것입니다..

---------

 

가 맞습니다. 멤버 인포는 자기 자체만으로 Key를 가지기에는 (논리상, 사실상, 객관적) 불가능하기 때문에 부모 엔티티의 애트리뷰트를 가지고와서 키로 삼아서 자기 자신을 구별하겠다는 의지 (방법A)고

 

방법B는 난 부모 필요 읎~~~따.. 난 독립하겠다. 부모가 있든지 말든지 상관 안하겠다~ 난 나다.. 라는 불효자를 용납하고서라도 자기를 독특하게 구별하겠다는 의지의 발로(?)입니다.

 

뭐... 설계하고 개발하는 차원에서는 Key를 작게 유지하는 것이 훨~씬 쉬운 유혹적인 방법입니다. (하지만 이렇게 하면 가령 Join 연산일 경우 한차레 더 일어나야 Member _name의 Attribute에 접근할 수 있습니다.) 쩝... 전 게을러서 그래도 키를 작게 유지하는 것을 더 좋아 합니다... ^^ 정말 나쁜 버릇이죠. ^^

 

 

글구 방법A를 사용하는 것은 약간의 물리적 저장장치를 손해 보더라도 Join을 줄여서 퍼포먼쓰에 이득을 꾀하는 방법일 수도 있고... 그 반대로 물리적인 공간을 줄이는 반면 컴퓨러야 너만 믿는다고 컴퓨터에게 가혹행위(Join)을 시키며 편하게 작업하는 방법은 B 일수도 있습니다.

 

어떤 성격의 Data냐에 따라 틀리겠죠. :)

김대성님이 2003-01-28 22:27에 작성한 댓글입니다.
[Top]
No.
제목
작성자
작성일
조회
667게임에 디비를 넣을려고 하는데....좀 알려주세요^^ [1]
이창신
2003-01-12
4678
666DB 설계를 하려고 하는데 죽겠습니다~ 답변좀 부탁드립니다~ ^^ [2]
초보자
2003-01-09
5412
665[질문]테이블 설계에 대해서 [2]
박주현
2003-01-09
4937
662제목 : 테이블 설계: 참조하는 방식 두가지 조언구함 [2]
스키마
2003-01-08
6931
660[좀 급합니다.]데이터 출력포맷에 대하여 [2]
김홍원
2002-12-26
5214
659DB쪽으로 공부할라하는데 어떻게 시작해야하나요? [1]
김종길
2002-12-23
5444
658SQL표준화 협회 [1]
백은미
2002-12-20
5786
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다