 테이블 설계.. 도와주세요. | General Discussions (일반 사항) |
2007-07-03 오후 3:28:48 |
|
업체에 따른 품목에 따른 제품규격에 따른 가격의 변동을 관리해야 합니다.
{등록일, 업체명, 제품명,
규격(다양), 가격}
이렇게 데이터가 쌓여야 하는데 문제는 규격이 유동적이라는 점입니다.
이 데이터를 가지고 현황을 뽑을 때 규격별로
뽑아야 하거든요.
2007-06-03, 삼성전자, 세탁기0001, 드럼02, 다리01, 호스02, ....,
500,000원
2007-07-21, 삼성전자, 세탁기0001, 드럼02, 다리01, 호스02, ....,
510,000원
2007-08-09, 삼성전자, 세탁기0001, 드럼02, 다리01, 호스02, ....,
520,000원
2007-06-03, 삼성전자, 세탁기0002, 드럼04, 호스01, ....,
400,000원
2007-07-22, 삼성전자, 세탁기0002, 드럼04, 호스01, ....,
490,000원
2007-05-03, 삼성전자, 세탁기0003, 다리21, 호스06, ....,
800,000원
2007-06-25, 삼성전자, 세탁기0003, 다리21, 호스06, ...., 750,000원
2007-07-12,
삼성전자, 세탁기0003, 다리21, 호스06, ...., 880,000원
규격이 유동적으로 들어가고 정해진 규격의 가격의 이력이
관리되어야 하는데
테이블을 어떻게 만들어야 할지 모르겠어요.
간단한 방법이 없나요?
카테고리를 써야 하나요?? 이건자신이
없는데... ㅜㅜ
규격을 "드럼02/다리01/호스02/.../.../" 이렇게 묶어서 컬럼에 넣을 생각도 하고
있습니다.
그럼 현황 뽑을 때 죽어나요...TT;
도와주세요.
|
|
|
|
|
|
|
|
 [답변]간단한 방법이라.. |
2007-07-03 오후 3:54:55 |
|
안녕하세요.
언뜻 생각하기에는 정해진 규격에 대한 테이블이 있고, 규격에 대한 가격 테이블이
따로 있어서 일자별로 가격의 이력을 갱신하는 형태로 가야 할 것 같은데요. 규격의
가격을 참조하는 것은 경우에 따라 가격 테이블을 조인해서 가장 최근의 가격만 가져올
수도 있겠고, 아니면 가격 테이블에는 최종 가격을 제외한 가격의 이력만 넣어놓는다든가
하는 방법이 있겠네요. (물론 이건 예전 가격의 이력이 그다지 많이 참조되지 않고,
최근 가격이 자주 참조된다는 가정 하에)
가장 필요한 것이 성능인지 편의성인지,
만약 성능이라면 어떤 컬럼이 자주 조회되는지, ... 라는 식으로
우선순위를 설정하고 그걸 정리해보신 다음에
차근차근 방법을 찾아보시면 쉽게 찾을 수 있으시리라 생각합니다.
그럼 : )
|
|
|
|
|
|
|
|
| [답변]답변 감사합니다.. |
2007-07-03 오후 4:19:19 |
|
단기간에 많은 데이터가 쌓이지 않으니 성능의 고려는 않해도 되요.
님의 말씀은 {업체, 제품명}--{사양1,사양2,사양3,사양4,..., 최근가격}--{날짜,가격}
└-{날짜,가격}
└-{사양1,사양2,사양3,...,
최근가격}--{날짜,가격}
└-{날짜,가격}
└-{날짜,가격}
└-{날짜,가격}
이런식의 구조를 말씀하시는지?
그런데 문제는 저 {사양, 최근가격}의 테이블을 어떻게 만드느냐 입니다.
{제품테이블_id, NULL, NULL, NULL, NULL, NULL, NULL, NULL,NULL, NULL,
NULL, NULL, 최근가격}
이렇게 컬럼을 꾀 여러게 만들어서 할 까도 생각했습니다.
혹시 참고할 만한 예제가 있으면 알려주세요..
|
|
|
|
|
|
|
|
| [답변]심플하게 적어보자면... |
2007-07-03 오후 4:39:53 |
|
{제품ID, 업체, 제품명}
ㄴ{사양ID, 제품ID, 사양1,사양2,사양3,사양4,..., 최근가격}
ㄴ{가격내역ID, 날짜, 사양 ID, 가격}
제품ID-사양ID, 사양ID-가격내역ID가 각각 일대다 관계를 갖는 거지요.
새로운 가격이 추가되면,
특정 제품ID의 사양ID를 쿼리해서 현재 시간으로 최근가격을 가격내역 테이블에
Insert하고,
새로운 가격은 해당 사양 테이블의 레코드를 Update하고.
위 사양1~사양n의 경우 사양의 최대 n이 미리 고정되어 있다면 저런 식의 테이블
구조를 유지하면 될 것이고,
어디까지 추가될지 알 수 없다면 제품-모델-사양처럼 관계 하나를 더 추가해야
할지도 모르겠네요.
참고할만한 예제라...
죄송스럽지만 딱히 떠오르는게 없네요 -_-;
이정도로 도움이 되셨을지..
|
|
|
|
|
|
|
|
| [답변]그림을 그려보았어요. ^^ |
2007-07-03 오후 5:15:31 |
|
님의 말씀데로 그림을 그려 보았습니다.
맞나요?
그런데 사양n이 정해져 있지 않습니다. ㅜㅜ
그냥 n을 100 정도 확보해서 NULL 로 가는게 좋을지?? 100까지는 않갈꺼 같거든요.
|
|
|
|
|
|
|
|
| [답변]네 : ) 이런 형태이기는 한데- |
2007-07-03 오후 6:07:20 |
|
이런 형태에서 어떤 식으로 만드는게 나중 작업이 편할지 고려해보시면 되겠죠.
사양n이... 글쎄요 뭐 그렇게 엄청나게 많지 않다면 큰 문제는 안 될 것 같습니다만.
나중에 특정 사양을 쿼리해야 할 일이 있다든가(예를 들면 드럼A를 사용하는 세탁기
조회...) 하면 쿼리문 작성이 궤로워지겠죠.
물론 그런 조회가 아예 없다고 한다면 상관은 없겠지만, 사양이 일종의 부품 개념이라고
한다면 저것도 분리해두시는게 나중에 좋을 것 같습니다. 쿼리의 편의성도 좋지만,
그렇다고 데이터가 일관성을 잃으면 곤란하니까요.
그리고 대규모 테이블이 아니라면 .. 일단 만들어 보세요.
정 아니다 싶으면 새로 테이블 만들고 데이터 옮기면 되죠 뭐.
그럼 : )
|
|
|
|
|
|
|
|
| [답변]네. 감사합니다. |
2007-07-03 오후 7:00:31 |
|
네. 감사합니다.
일단 이렇게 가야 겠네요.
나중에 정 않되면 말씀데로 옮기면 되겠죠.. ^^
|
|
|
|
|
|
|
|
|