물리 모델링 단계에서 무엇을 해야 하는지요?

현재 파견나와 있는 사이트에서 물리 모델링 단계에 들었습니다.

그동안 했던 고민을 다시 하게 되네요. ㅎ

 

논리 모델링까지는 업무를 중심으로, 물리 모델링에서는 성능을 중심으로 설계하는 게 정설이지만 다른 분들은 고민이 없는지 모르겠습니다.

저는 통합을 해야 하는지에 대한 고민 등과는 다른, 원초적인 고민을 하게 됩니다.

 

기간상 모든 테이블에 대해 성능을 고려하는 것은 힘들다는 등의 현실적인 사실은 차치하고라도 업무와 성능을 나눠서 생각할 수 있는지도 의문입니다.

만약 나눠서 생각할 수 있다면, 과연 업무와 성능을 나눠서 생각하는 게 효과적인지요?

 

업무가 없는 상태에서 요건을 분석해서 모델링 하는 경우, 과연 물리 모델링 단계가 필요할까요?

데이터가 없는데 어떤 기준에서 성능을 판단할까요?

 

리버스 모델링이라면 이미 데이터를 계속 경험했기 때문에 성능이 업무의 일부분이 되니, 오히려 따로 나눠서 생각하기 힘들지 않을까요?

 

많이 고민한 부분이고, 제 책에도 그 고민을 살짝 썼는데요.

모델링은 종합적으로 생각해야 잘 할 수 있는 분야이지 기계적으로 실행해서 잘 할 수 있는 분야는 아니라고 생각합니다.

나눠서 생각하는 타스크 중 일부는 효과적이지 않습니다.

 

데이터와 쿼리가 존재해서 실험해볼 수 없는 한(이는 사실 모순입니다) 물리 모델링 단계에서 성능을 고려할 수 없습니다. 그것이 추측이거나 경험을 그대로 반영한 것이 아니라면요.

 

그리고 그것이 추측이거나 경험을 그대로 반영한 것이라면 이전 단계에서 한 번에 반영하는 것이 효과적이라는 생각이 듭니다.

 

제가 경험한 게 대부분 마지막 1개월이 물리 모델링 기간이었기에 이런 생각이 드네요.

 

만약 업무만을 반영한 논리 모델로 DB를 생성한 후에 개발을 시작한다면.

그래서 개발 중에 성능 문제와 관리 비효율이 생겨 그걸 해결하는 과정을 물리 모델링으로 본다면 물리 모델링이 재미있을 거 같아요.

실제로 성능 중심으로 설계한 물리 모델링이니까요. 영문 위주의 작업이 아니니까요.

 

최근 몇 가지 한계 때문에 모델링이 재미없다고 생각한 적이 있지만, 모델링은 즐거운 작업입니다.

 

실제 데이터와 화면(SQL)을 보고 문제를 해결해 나가는 과정(물론 인덱스 설계가 기반이 돼야 하고요).

조만간 이런 프로세스가 생길 거라고 기대해도 될까요. ㅎ

 

물리 모델링 단계에서 어떤 일을 해야 하는지요?

전체의 6분의 1 정도나 되는 기간에 해야 할 일이 있는지요?

물리 모델링 단계가 제일 바쁘다는 등의 의견 말고요. ㅎㅎ