반응형
현업에서 일을 하다보면 DB 모델링을 하는 경우가 많다.
어떤경우에는 PK / FK 관계를 이용해서 모델링 하는것이 바람직 하지만, 개발의 업무 효율상
PK/FK관계를 걸지 않고 UI(Unique Index)만 걸고 작업을 하는 경우가 많다.
이 둘 경우의 차이에 대해 공부하고 어떤상황에 적절히 쓰는것이 좋은지 글을 써 보도록
하겠다.
[1] PK & UI 차이점
우선적으로 PK 와 UI를 사용했을때 어떠한 차이점이 있는지 아래 표를 보도록하자.
위 표는 데이터 베이스 관련 블로그 북을 통해 타인의 지식을 가져온 것이다. 내 생각을
좀 넣으면 특정DB에 따라 UI의 경우 Null값이 Colume에 들어있을경우 해당 필드는 Index
검색을 타지 않는 것을 알게되었다.
[2] UI 를 사용했을때의 장점
UI만을 사용하여 DB모델링시 에는 어떠한 장단점이 있는지 한번 알아보자.
[3] PK/FK 를 통한 모델링 방법
이번엔 PK/FK를 이용한 모델링에서의 장단점을 알아보도록 하자.
[4] 어느것을 쓰는게 더 좋을까?
위에서 보듯이 PK/FK 방법의 단점은 거의 없다. 하지만, 어떤경우 UI만 가지고 모델링을 하느냐? ... 실제 필자가 과거 제로보드 XE버젼시기에 DB를 역공한 해본 경험이 있다.
모든 DB가 각각의 테이블이 존재하며 어떠한 관계도 엮어 있지 않은 것을 발견하였다. 그렇기 때문에 ER-D상으로 DB의 관계를 파악하는데 상당한 시간이 소모되었던 경험이 있다. 또한, 복잡한 테이블의 관계를 단순 느낌으로만 파악해야하는 것은 SM하는 입장에서 매우 좋지 않다. 마지막으로, 이미 개발되어진 부분을 수정시 참조 무결성을 타지 않아 , 무분별한 DML 작업이 가능했었다. Data란 퍼즐과 같다, 한부분이 깨지면 금방은 티가 나지 않지만, 시간이 지날수록 그 공백을 메우는 것은 불가능에 가깝다.
무결성이란 것은 왜 중요한가? 실제 db상에서 무결성을 지켜주지 않는다면, 개발자 입장에서는 Application에서 Transaction이나 또는, Syncronised 와 같은 동기화 를 이용하여 개발해야하는 번거로움이 있기 때문이다.
[5] 성능저하 문제
실제로 UI만 거는것이 성능에서는 월등하다는 편견을 가진 여러 책 또는 개발자들을 만나보았다. 내 생각은 이렇다. 과거 하드웨어적인 성능이 잘 따라주지 않았던 2000년도 이전 시기에는 pk/fk 가 성능을 떨어뜨린 적도 있었다. 하지만, 그것보다도 PK/FK 관계에서 FK에 대한 적절한 Index를 걸어주지 않아, Full Scan을 타버렸기 때문이다. 잘알고 적절히 쓴다면 크게 성능차이는 존재하지 않는다고 생각한다.
[6] 실제 UI를 이용한 사례
필자가 읽은 책에서 보았을때 전세계에서 유명한 ERP 프로그램인 SAP ERP / ORACLE ERP는 UI로만 모델링되어있다고 한다. 그 이유는 ERP 자체가 One Souce Multi Use 의 특징을 가지고 있기 때문이다. 각각의 ERP는 어떤 비지니스 환경이든 동일한 소스를 심어야 한다. 하지만 PK 가 절대적으로 고정되어 있으면, 일부 flexible을 요구하는 Site에서는 문제가 야기될 여지가 있기 때문에 내부적으로 차이가 있는 비지니스 모델을 수용하기 위해 UI를 종종쓴다.
위 내용에는 1가지 전제조건이 있다. 많은 테스트를 통해 Application에서 참조무결성을 지켜주어야 한다는것이다. 실제 위 프로그램의 경우 각 DB의 DBMS들이 소스코드를 통해 무결성을 유지하는 역할을 하는 로직을 포함하고 있기 때문에 PK/FK 가 걸려있는 것과 사실상 다를것이 없다.
[7] 마지막.
아 밤에 뭔짓인가 ... 엄청길게 썼네~~~ 괜시리 필받아서 ㅋㅋㅋㅋ
개발자 관점에서 DB를 얼마나 아느냐가 중요하다. 적절히 Query만 아는것도 크게 나쁘지는 않다. 하지만, DBA의 관점까지 접근가능하다며 더 좋은 소스코드를 만들수 있을것이다. PK/FK를 쓰느냐 UI를 쓰느냐,,, 대규모 프로젝트가 아닌이상 성능상의 퍼포먼스는 차이가 없다. 하지만, 자그마한것 하나하나 몸에 습관을 들여놔야만, 좋은개발자가 될 수 있다.
이상
- 2011.01.31 랑이씀 -
출처 : 아는만큼 보이는 DB 참조.
기타 타 웹사이트 참조
어떤경우에는 PK / FK 관계를 이용해서 모델링 하는것이 바람직 하지만, 개발의 업무 효율상
PK/FK관계를 걸지 않고 UI(Unique Index)만 걸고 작업을 하는 경우가 많다.
이 둘 경우의 차이에 대해 공부하고 어떤상황에 적절히 쓰는것이 좋은지 글을 써 보도록
하겠다.
[1] PK & UI 차이점
우선적으로 PK 와 UI를 사용했을때 어떠한 차이점이 있는지 아래 표를 보도록하자.
| 항목 | PK | UI |
| 목적 | Constraint + Index | Index |
| 공통점 | 유일성 보장 | 유일성 보장 |
| 참조 무결성 | PK/FK에 의해 지정가능 | 지정 불가능 |
| 테이블당 개수 | 1개만 가능 | 여러 개 가능 |
| 인덱스 생성 | Unique Index 생성 | Unique Index 생성 |
| NULL 허용 | 허용 안됨 | 허용됨 |
위 표는 데이터 베이스 관련 블로그 북을 통해 타인의 지식을 가져온 것이다. 내 생각을
좀 넣으면 특정DB에 따라 UI의 경우 Null값이 Colume에 들어있을경우 해당 필드는 Index
검색을 타지 않는 것을 알게되었다.
[2] UI 를 사용했을때의 장점
UI만을 사용하여 DB모델링시 에는 어떠한 장단점이 있는지 한번 알아보자.
| 장점 | 단점 |
| - Relation이 걸리지 않아 DBA가 테이블 수정, 적용 등이 용이하여 관리하기가 수월하다. | - 데이터의 무결성이 깨질 수가 있다. - 무결성이 깨지는 경우를 대비하여 마이그레이션 및 각종 백업,복구작업시 데이터 정리 작업이 필수적이다. |
| - 개발자 관점에서 Relation을 생각 하지 않아도 되기때문에 개발서 DB Lock , Transaction 관리등에 대해 다소 덜 신경써도 된다. | - Bean과 같은 데이터 모델과 테이블이 일치 하지 않아도 상관없는 방식 이기 때문에 개발모델구상시 모델관리가 불편함이 있다. |
| - PK/FK 를 사용하지 않기 때문에 특정 DB모델에서는 성능이 좋아지는 효과를 얻을 수 있다. | - UI는 한 테이블에 다수를 걸수 있으므로, PK가 무엇인지 육안으로 구분하기가 힘들다. |
[3] PK/FK 를 통한 모델링 방법
이번엔 PK/FK를 이용한 모델링에서의 장단점을 알아보도록 하자.
| 장점 | 단점 |
| - 무결성이 보장된다.( 무결성이 보장된 다는것은 데이터 관리면에서 매우 중요한 문제이다.) | 없음 |
| - 추후 Reverse Engine을 돌릴 시에 PK/FK의 관계는 역공학이 가능하다. | 없음 |
| - FK를 사용해도 적절히 인덱스만 걸어준다면, 성능 저하 현상은 나타나지 않는다. | 없음 |
[4] 어느것을 쓰는게 더 좋을까?
위에서 보듯이 PK/FK 방법의 단점은 거의 없다. 하지만, 어떤경우 UI만 가지고 모델링을 하느냐? ... 실제 필자가 과거 제로보드 XE버젼시기에 DB를 역공한 해본 경험이 있다.
모든 DB가 각각의 테이블이 존재하며 어떠한 관계도 엮어 있지 않은 것을 발견하였다. 그렇기 때문에 ER-D상으로 DB의 관계를 파악하는데 상당한 시간이 소모되었던 경험이 있다. 또한, 복잡한 테이블의 관계를 단순 느낌으로만 파악해야하는 것은 SM하는 입장에서 매우 좋지 않다. 마지막으로, 이미 개발되어진 부분을 수정시 참조 무결성을 타지 않아 , 무분별한 DML 작업이 가능했었다. Data란 퍼즐과 같다, 한부분이 깨지면 금방은 티가 나지 않지만, 시간이 지날수록 그 공백을 메우는 것은 불가능에 가깝다.
무결성이란 것은 왜 중요한가? 실제 db상에서 무결성을 지켜주지 않는다면, 개발자 입장에서는 Application에서 Transaction이나 또는, Syncronised 와 같은 동기화 를 이용하여 개발해야하는 번거로움이 있기 때문이다.
[5] 성능저하 문제
실제로 UI만 거는것이 성능에서는 월등하다는 편견을 가진 여러 책 또는 개발자들을 만나보았다. 내 생각은 이렇다. 과거 하드웨어적인 성능이 잘 따라주지 않았던 2000년도 이전 시기에는 pk/fk 가 성능을 떨어뜨린 적도 있었다. 하지만, 그것보다도 PK/FK 관계에서 FK에 대한 적절한 Index를 걸어주지 않아, Full Scan을 타버렸기 때문이다. 잘알고 적절히 쓴다면 크게 성능차이는 존재하지 않는다고 생각한다.
[6] 실제 UI를 이용한 사례
필자가 읽은 책에서 보았을때 전세계에서 유명한 ERP 프로그램인 SAP ERP / ORACLE ERP는 UI로만 모델링되어있다고 한다. 그 이유는 ERP 자체가 One Souce Multi Use 의 특징을 가지고 있기 때문이다. 각각의 ERP는 어떤 비지니스 환경이든 동일한 소스를 심어야 한다. 하지만 PK 가 절대적으로 고정되어 있으면, 일부 flexible을 요구하는 Site에서는 문제가 야기될 여지가 있기 때문에 내부적으로 차이가 있는 비지니스 모델을 수용하기 위해 UI를 종종쓴다.
위 내용에는 1가지 전제조건이 있다. 많은 테스트를 통해 Application에서 참조무결성을 지켜주어야 한다는것이다. 실제 위 프로그램의 경우 각 DB의 DBMS들이 소스코드를 통해 무결성을 유지하는 역할을 하는 로직을 포함하고 있기 때문에 PK/FK 가 걸려있는 것과 사실상 다를것이 없다.
[7] 마지막.
아 밤에 뭔짓인가 ... 엄청길게 썼네~~~ 괜시리 필받아서 ㅋㅋㅋㅋ
개발자 관점에서 DB를 얼마나 아느냐가 중요하다. 적절히 Query만 아는것도 크게 나쁘지는 않다. 하지만, DBA의 관점까지 접근가능하다며 더 좋은 소스코드를 만들수 있을것이다. PK/FK를 쓰느냐 UI를 쓰느냐,,, 대규모 프로젝트가 아닌이상 성능상의 퍼포먼스는 차이가 없다. 하지만, 자그마한것 하나하나 몸에 습관을 들여놔야만, 좋은개발자가 될 수 있다.
이상
- 2011.01.31 랑이씀 -
출처 : 아는만큼 보이는 DB 참조.
기타 타 웹사이트 참조
반응형
'DB > Maria & Mysql' 카테고리의 다른 글
| MYSQL 자주쓰는 명령어 (0) | 2012.09.10 |
|---|---|
| [ MYSQL PROCESS LIST 보기 ] (0) | 2011.12.27 |
| [ Mysql Concat 한글깨짐 ] (0) | 2011.01.13 |
| [ WINDOWS OS 에서 MYSQL5.X ROOT 비밀번호 분실] (0) | 2011.01.04 |
| MYSQL Tinyint(1) 의 의미 (2) | 2010.07.27 |
