db 테이블 설계 미묘한 질문입니다 어느게 나을가요?13
- 고수롱이징
- 등록일 2015-03-30 05:09
- 조회수 1478
|
||
0
추천하기
다른의견
0
|
파워링크 
등록안내
등록안내
|
 0
 0
봄-봄
예시1, 예시2 모두 정상적인 설계가 아닌데요.
사원 한명이 가지고 있는 정보가 200개 이기 때문에 컬럼 200개 만든다는 얘기 같은데... 정보의 관계 및 조회 빈도 등을 고려해서 몇개로 그룹화하여 정규화 시켜 사용해야지... 매번 무조건 200개의 정보를 모두 동시에 조회하는게 아닌이상 한테이블에 넣는건 비효율적입니다. |
|
0
1
봄-봄
엇 열심히 답글 작성중이었는데, 최초 답글을 변경하셨네요..;;
일단 이 답글에 대해서는, 일단 정규화 해두고 전체 필드 노출은 보여줄떄만 정규화한 데이터를 조인하여 보여주어야 하는거죠. ------------------------------------------------------------------------------------------------------------------- 아래는 지워진 첫번째 답글을 보고 작성한겁니다. 일단 해당 시스템 분석해야하나..모르니 상식적으로 나름대로 설계해보죠. 사원 정보를 조회할때 항상 무조건 급여정보 보는게 아니지 않나요. 당연히 급여 정보는 분리해야죠. 사업부, 부서는 나중에 특정 사업부, 부서의 사원들만 조회할 수도 있으니 정규화 해야하고, 직급이나 직위는 보통 사업부,부서와 연계해서 조회하지 단일 키워드로 조회할거 같진 않고 갯수도 적으니 코드와 하지 않고 명칭만으로 그대로 역정규화해서 놔두고... 그러면 적어도 말해준 것만으로도 테이블을 다음과 같이 구성 하겠네요. 사원 테이블 : 사원번호(pk), 사원명, 부서코드, 직급명, 직위명 -- 사업부는 부서코드로부터 조인해서 찾아감 사업부 테이블 : 사업부코드(pk, 2자리), 사업부명 부서 테이블 : 부서코드(pk, 4자리), 사업부코드, 부서명 -- 부서코드는 사업부코드(2자리) + 부서코드(2자리) 형태로 구성, 부서코드만 봐도 사업부를 알 수 있음. 단 사업부코드를 별도로 컬럼으로 뺀것은 인덱스를 고려한것임 급여정보 : 사원번호(pk), 기본급, 상여금, 식대, 급여히스토리(옵션) : 사원번호(pk), 시작일(pk), 종료일, 기본급, 상여금, 식대, 변경이유 제가 적은게 정답은 아니겠지만, 적어도 이정도로 DB 설계할때 고려는 해야합니다. 위 내용에는 적어도 다음과 같은 상황이 고려된겁니다. 1. 어떻게 조회하는가? 2. 인덱스를 어떻게 구성할 것인가? 3. 데이터의 분배를 어떻게 할것인가. (히스토리는 자주 조회하진 않고 데이터는 많겠죠. 나중에 이건 일자로 파티셔닝 해서 관리합니다.) 4. 코드의 사용성 고려. |
|
0
1
![[* 비회원 *]](http://cdn2.ppomppu1.co.kr/zboard/nickcon/155047.gif?v=20240916)
먼저 결론을 내자면, 작성자가 문제네요
1. 컬럼이 999개든 문제가 될건 없는데 조회를 뭘 하느냐 이지.. 결국 이 이야기는 정규화도 , 역정규화도 안했다는 이야기.. 이걸 과연 쓸 수 있을런지가 의문.. 2. 360만이 많다고 생각하나 본데 3600만이 아니라 3.6조도 많은게 아닙니다. 전부를 조회할 것도 아니고 조회를 하는 방법의 차이 일뿐 일례로 제가 가는 고객사 중 한곳은 20년치 데이터를 조회하는 곳이 있습니다. 20년치면 엄청난 데이터겠죠? 이럴 경우 기존의 시스템 구축이 아닌, 전혀 다른 방식으로 새로 구축을 해야 할 수도 있습니다. 그런데 못고친다고 하니 전 간단히 한가지 방법을 제시했습니다. '서버 놀때 미리 돌려두세요' 사용법이 명확하면 답은 쉽게 보입니다. |
|
|
0
0
입쑬입쑬
설계가 변경되어야 할거 같긴 하지만..
질문하신내용은 아마 제가 알기로는 차이가 없는걸로 알고있어요~ 옵티마이저가 데이터를 퍼올릴때 200 x 3만 = 20 x 30만 = 600만 요렇다고 언젠가 대용량디비 강의에서 들었던 기억이 있네요ㅋ |
|
|
0
0
전투감각
row 구조를 읽으면 함수호출 될거고, 이 함수는 컬럼포인터로 계산할 것으로.. 아마 루프돌지않을겁니다.
그래서 rows가 많으면 호출수가 많아지고 느려질 듯 합니다. col으로 읽는 경우에도 row포인터계산으로 루프돌지 않을 겁니다. 그래서 cols가 많으면 호출수가 많아지고 느려질 듯 합니다. 제 생각에는 정방형 크기가 적당한 거 같습니다. |
|
|
|
 |
|
| △ 이전글▽ 다음글 | 목록보기 |
|
용도에 따라 다를수도 있겠지만 뭐..
제 입장에선 뻐큐먹어 시스템인데요?ㅋ
저정도 고민을 하시는거 보니 현직은 아니신가봅니다?