이곳 dsn의 자료가 요청하신 자료보다 많습니다. 잘 돌아가잖습니까. ^^

그 정도면 규묘가 작은 편입니다.
제가 보기에는 설계만 잘 하시면
쓰는데 전혀 무리가 없을 듯싶네요. 

월 평균 판매건수로 100만건을 거뜬히(?) 운영하고 있습니다.
판매자료에 대한 로우 단위를 계산하면, 약 300만 row는 되죠. 

관건은 어떻게 자료설계를 하느냐인듯싶습니다. 

자료 저장은 하드디스크 풀날 때까지일터이고..
어차피 대용량이 되면 원천거래자료의 분리는 불가피해지니. 

제일 걸리는 것은 동시접속을 200 client가 db에 바로 붙는다는 것인데,
이렇게 되면 db의 내부적인 테이블, row 잠금현상에 대해서 잘 알고 있어야할겝니다.
그렇지 않으면, 많이 쓰는 시간에는 조금만 착각하면 바로 전체 클라이언트들이 다 버벅거릴터이니 말입니다.

이런 고민을 하지 않으려면,
아마 가운데 미들웨어가 하나 있어서 db 작업에 대해서는 한번의 교통정리를 해줘야하지 않을까싶기도 합니다. 

클라이언트의 db 요청이 들어오면, 그놈을 직능별로 큐에 쌓아두고 하나씩 db로 보내고 db결과를 다시  클라이언트로 보내는 기능을 미들웨어가 맡아서 db 잠금현상을 최소화하는 것이 마땅하지 않을까싶습니다. 

이부분은 비싼 db건 공짜 db건 모두 마찬가지 이야기입니다.

상기님 그럼  . . .  그런 용도를 쓸수 있는 미들웨어 추천을 한번 해주세요 . . . 

오픈소스면 좋구요  . . 

아님 돈 작게 들어가는 상용이라도   . . . . 

부탁드립니다.... 감사 ^^;

만들어서 쓰는지라 모릅니다. ^^
C++로 만들어서 쓰는데, 맨날 AC8, AC8 연발입니다. -.-


이런 3-Tier 방식의 미들웨어는 업무흐름과 관계가 되기 때문에 
대부분 중소기업에서는 포기를 하고, DB - client 형태의 2-Tier 방식을 쓸 수 밖에 없습니다.
반면 대기업에서는 외주형태의 솔루션을 구매합니다. 
은행같은 경우는 수억대죠? ^^

중소기업용으로 누가 만들어주려나싶네요.
왜냐하면 그 기업의 기반이 되기 때문입니다. 
장애시 대처에 대한 부분도 이 가운데 있는 놈이 제일 할일이 많거든요.

한번 찾아보시고 개발하려는 프로젝트에 딱 맞는 놈이다 싶으면 그것을 써보시고, 
그렇지 않다면, 일단은 2-Tier 방식으로 설계해서 납품하고, 
문제가 생기는 병목현상들을 차근히 고쳐가는 방식을 택하셔야할 듯싶습니다.

-_- , , , ,,  역시  . . .  

'병'에 '목'이 왜있는지 모르겠네요 . .  -_-  . . . 

가끔 병목이 사람목을 죄는 지라 . . .  허걱 . . . 

함 찾아봐야겠습니다. . . .  도저히 개발할 능력은 안되고요 . . .

감사 . .  ^^