[지식]스터디톡 내용 정리

같이 스터디를하는 개발자분께 질문드렸던 내용인데 도움이 많이되어 정리..

저에게는 도움이 되어서 정리했는데 도움됬으면 좋겠습니다. ㅎㅎ  

 

 

1.프로젝트를 6개월 단위나 단위로 작업하게되면

관련된거를 다 문서화하는가?

 

--> 산출물이 있기는하나 거의 막판에 같이 작성한다.

그때 그때 산출물 작성이 좋기는 하지만

(개발이 바빠서 산출물 챙기기는 힘들다)

 

산출물은 개인거는 아니고 프로그램 개발시 제출해야한다.

(개발이 중요하지 크게 신경쓰지 않아도 된다)

 

2.프로젝트시 신입이 가지고있어야할 최소역량이 어떤거라고 생각하시냐

 

-->습득력이라고 생각한다.

    하나를 알려줬을때 자기거를 만드는 능력.

    그리고 그런걸 종합적으로 생각하고 응용할 수 있는 능력

 

처음에는 다 모르니까 / 그렇다고 또 하나하나 100%찝어서 알려줄수도 없기에

 

==>어느정도는 자신이 해결해 가면서 묻고

생각하면서 자기것을 만들어가는 능력이 중요하다고 본다.

 

 

3.대부분의 업무 프로그램은 프로그램적인 큰 기술은 없다

특이한 경우를 제외하고는

데이터 조회, 입력, 수정 , 삭제가 대부분이다.

 

==>항목이 다르지만 행해지는 로직은 다 비슷하다.

 

실무로 들어가게되면 SI의경우 개발 초기에 표준을 다 잡는다.

-->나머지 개발자들은 그 표준에 의해서 개발한다.

-->그래야 생산성이 커지니까.

 

4. 어제 user 생성시 오류났던부분 테이블스페이스 먼저 만들고

유저 생성해야하는데 만들지 않고 유저 먼저 생성해서

오류가 난거같다.

 

-->그래서 어제 디폴트 제거했을대는 쿼리문이 실행된 이유가

유저만들어서 비밀번호랑 아이디 지정해서 만들었는데

테이블 스페이스를 안만들어놔서 디폴트를 제거한 상태로

쿼리문을 실행해서 완료된거냐?

 

-> 그렇다. 기본테이블스페이스로 지정된다 .

 

6.decode함수를 사용해서 쿼리문 보여주신적이있는데

그때 굳이 줄일필요가 없다고 말씀주셨는데 그렇다면

언제 쿼리를 수정하나?

 

-> 새로운 화면이 생겨나면 새로짜고  기존에서 항목이 변경되거나 어떤 내용을 더 보고싶을때 수정한다.

 

----> 내가 디코드 이 질문을 전에  왜했나? 디코드 함수가 나열되어있는데 비슷하고 0 ~9이렇게 번호만 연속적으로

늘어나길래  저부분을 좀쿼리를 줄일수없나 하고 질문했었던 내용이였다.

(아래 7번과 이어지는 내용)

 

7.쿼리문은 길고 짧은게 문제가 아니다. 결과의 속도다.

-->쿼리문이 길다고 속도차가 나는게 아니라. 쿼리 구성을 어떻게 하느냐가 관권이다.

 

 ex)) 10,000개의 데이터와 50,000개의 데이터를 조인할 경우에 그냥 조인했을 경우와,

조건에 따라 10,000개를 100개로 줄이고

100개와 50,000개를 조인했을때 어느게 더 빠를까 그런 문제다.

 

-->조인 방법이나 순서를 최적화하라는 말씀이시냐  -->!그렇다 그게 관권이다.

 

==>오라클의 생리를 알고 인덱스를 태우고..등등 인덱스를 태우고 안태우냐에 따라 속도는 상상이 안간다.

 

많은거에서 적은거 조인하는게 나은지

적은거에서 많은거 조인하는게 나은지

 

몇개의 규칙만 알면 쿼리결과에 문제가 없다고 본다.

 

-->오라클의 생리를 알고 sql튜닝 관련해서 생각을 많이 해보고 활용을 해야군요!

 

==>우선 기본만 정확히 알면 튜닝까지 안가도 된다고 본다.

튜닝까지 가야 할 데이터면 통계 테이블이나 집계 테이블을 만들어서 하는게 더 효율적이다.

 

ex))예를들어 방문자 보는 테이블이 있을때 하루에 10,000명 정도 들어오는데

월 방문자를 새로면 310,000정도 카운트 되지만.

 

일 배치로 12시가 지나면 그날 방문한 사람 수 총합을 저장해 놓으면

31개를 카운트만 해도 월방문자를 알 수 있다.

 

1년방문자를 구하려면 --> 일방문사 x 월 x 12

 

-->작업단위로 묶어서  연속적으로 일괄처리해서 이용하면 효율적으로 쓸수있다 이런 내용이신가! ->그렇다.

 

 

예를들어 3년간 방문자 추이를 보고 싶다 하는데

 

로우데이터(하루하루방문자 SUM)해서 1년 방문자 숫자 파악하면..아무래도 비효율적이다.

 

그래서 사실 예전에 트리거라는것을 썻다.

방문자가 방문했을시 데이터 1개가 들어가면 -->월통계 테이블은 해당월에 +1되도록 자동으로!

 

 

==>근데 이런 부분은 실무를 하다보면 자동적으로 느끼고 배운다.

 

예를들어 휴대폰요금이나 이런거 산정하는거를 건건히 데이터화해서 사용하고 이러는데

결과를 보려면 3일이 걸렸는데--> 오라클튜닝업체에서 30초만에 결과가 나오도록 쿼리변경

(물론 집계테이블도 만들어서 배치도 돌리고 했을거다.) 

 

-->현재 저의 수준은 기사나 쿼리책에 나오는 기본쿼리문정도를 사용할줄알고 기억하고있다.

     DB공부시에 같이 나가는 책 목록에 있는 기본 사용법에 대해 잘 숙지하고 사용할 수 있을정도로

     공부방향을 설정하려고한다.

 

==>우선 기본적인 공부만하면 실제 능력은 실무에서 클꺼다.

공부에는 한계가 있다. 공부로서 이해안가는 부분이

실무에 가면 왜 이렇게 해야하는지 알 수 있기 때문에

책에서는 이론적인데  실무에서 이론적으로 안되는 경우가 대부분이라고 보면 된다.

 

이론적으로 10개중 7개는 맞는데 3개는 틀릴 수 있다.

그 3개는 응용해서 만들어야 하는데

그런걸 해결하느 센스가 필요하다.

(책에는 어느정도 한계가 있다.)

 

케이스 바이 케이스다.. 책에는 이렇게 되어있지만 경우에 따라 그렇게 안할 경우도 있기때문에.

 

경험을 많이해서 많이 아는게 좋다.

 

 

8.설계 관점에 대해..

 

내가 주무를 수 있다기 보단

고객 입장에 맞는 시스템을 전문가이 내가 어떻게 만들어 줄 수 있는가에 초점을 두면 된다.

 

고객이 니드하는바 -->캐치-->그에 합당한 프로그램을 만들기.

 

프로그램을 잘짯다고 잘짠게 아니라.

 

그 고객이 오오오오오! 제가 원한 프로그램이 이겁니다! 하는게 최고의 설계다 .