database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
ㆍ자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
자유게시판 자유게시판 4293 게시물 읽기
 
No. 4293
1
작성자
이진희(jinyedge)
작성일
2004-06-29 16:55ⓒ
2012-09-12 15:37ⓜ
조회수
3,280

1

이 글에 대한 댓글이 총 8건 있습니다.

Somewhere I belong 이 생각나는 이유는...

Xu(shyxu)님이 2004-06-29 17:21에 작성한 댓글입니다.

크....

 

진희님 밥묵고 하세요. ^^;

정재익(advance)님이 2004-06-30 09:40에 작성한 댓글입니다.

크크크...... 결국..... 결론은.....

 

"광부도 밥은 먹어야 산다." 라는 결론에 :-)

김주현님이 2004-06-30 23:26에 작성한 댓글입니다. Edit

 

iplanet 서버는 이쪽 밥먹고 살려면 필히 만져야 합니다.

좋은 공부하고 오셨네요. ^^;

 

진희야...

갑자기 왠 노래를...

날이 너무 더워 졌나...

정재익(advance)님이 2004-07-01 14:21에 작성한 댓글입니다.

역시 관공서 서버가 짱이야 ~~~...

 

좋은건 알아서 마구설치하고 관리는 아아서 되는줄 안다니깐 ...

헌종님이 2004-07-01 18:27에 작성한 댓글입니다. Edit

동감입니다. 사실 불필요한 IT예산 낭비되는 부분이 많지요.

 

문제는 그러한 돈이 하드웨어가 아니라 사람에게 투자했다면 우리나라 IT가 요모양 요꼴은 아닐거라는건 분명합니다.

 

말씀 하신 문제도... 결국 코딩을 엉망으로 한 것이고 사람이 투입되어서 해결되어야 하는 문제인데... 하드웨어로 땜빵(사실 땜빵도 아니죠)한 수준입니다. 비싼 외산 장비로 외국벤더만 배불리고 좋은일 시켜주는 셈이죠.

 

세상에 웹 페이지에 13만건을 한꺼번에 뿌리는 경우가 있을까요? 절대로 없지요. 결국 한페이지에 보여주는 분량은 많아야 100건을 넘어가지 않습니다. 개발자가 제대로 끊어서 뿌려줄 생각을 하지 않고 13만건을 몽땅 읽은 다음 끊어서 보여주니 느릴 수 밖에요.

김주현님이 2004-07-02 00:29에 작성한 댓글입니다.
이 댓글은 2004-07-02 00:38에 마지막으로 수정되었습니다. Edit

한화면에 13만건을 뿌린다는 이야기는 아니죠.

 

100건만 실재로 Fetch 해오는거라면... order by를 하든 Group by를 하든 볶아먹든 지져먹든 느릴 수가 없습니다. 자료량이 적으므로...

 

문제는 13만건에서 100건만 뽑아오는게 아니라... 13만건을 몽땅 가져와서 그걸 Order by, group by하고 나서 100건을 끄집어낸다는 겁니다.

김주현님이 2004-07-02 22:56에 작성한 댓글입니다. Edit

고생 많으셨습니다.

 

저도 비슷한 경우를 많이 봤지요. ^^;

무한 루프를 돌도록 짜놨는데... (exit 조건 체크도 안하나봅니다.)

그것 때문에 테이블 사이즈가 무한대로 늘어나더군요. 데이타는 겨우 수백건 들어있는데 말이죠.

 

관공서 같은데는 뭐 정치적으로 술사주고 그렇게 해결하는 경우가 많다고 들었지만...

 

일반 사기업들은 SI 단가가 너무 적게 책정되다보니까... 어쩔 수 없습니다. 프로젝트를 수주한 대기업 계열사의 대형 SI업체들도 자체 인력만으로는 도저히 단가를 맞출 수 없기 때문에 하청에 재하청을 안줄수가 없습니다.

결국에는 초급인력만 밀어넣어야 겨우 손익 계산이 나는 상황이다보니 고급 개발자는 넣고 싶어도 엄두도 못내죠.

그러다 보니.... 업무 분석 전문가나 모델링 전문가, DBA등도 없이 단순히 개발자만으로 진행되는 프로젝트가 대다수입니다.

전문 모델러나 DBA의 감리하에 어느 정도 SQL튜닝등이나 코드 품질을 검증한 것이 아니기 때문에 오픈 직후 엄청난 다운이나 장애를 겪게 됩니다.  튜닝이라는 것도 처음에 개발할 때 고려하면 비교적 쉽습니다. 하지만 이미 개발 완료되고 버스 떠나면 기존 코드를 죄다 고쳐야하기 때문에 (혹은 모델을 뜯어고쳐야하기 때문에...) 고비용이 되버리죠.

 

그래서 35세 정년이니 하는 말도 나오는거랍니다. 그 정도 스킬의 인력이 필요하지도 않을 뿐더러 수준에 걸맞는 높은 연봉을 주게 되면...업체가 생존해나갈 수 없습니다.

 

결국 자체 솔루션이나 패키지 쪽으로 나가야하는데 이 쪽은 일단 리스크도 크고 작은 업체에서 개발에서 상품화까지 감당하기엔 벅찹니다.

그리고 이런걸 할만한 큰 업체들은 이런 쪽에는 별로 관심이 없습니다.

 

김주현님이 2004-07-03 10:01에 작성한 댓글입니다. Edit
[Top]
No.
제목
작성자
작성일
조회
4296전반기 결산 잘 하셨나요. [1]
정재익
2004-07-01
2751
4295건의~ [7]
seha
2004-06-30
2836
4294xu와 닮은꼴..? -_- [7]
Xu
2004-06-29
3019
42931 [8]
이진희
2004-06-29
3280
4292BI(business intelligence) 에 대한 정리... [3]
허지숙
2004-06-29
3143
4290오라클 기술적 문제 어떻게들 해결하시고 계십니까? [3]
김주현
2004-06-29
3025
42891 [4]
이진희
2004-06-28
3444
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.017초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다