이 문제는요..

의견이 아마도 분분한 문제일 것으로 생각됩니다.

제 생각에는 데이타 관리 측면이나 가공성 등을 생각하면 당연히 DB에 넣는 것이 맞다고 봅니다.

그러나 CLOB 인터페이스가 잘 지원 안되는 언어나 툴등이 있다는 말도 있습니다.

반대로 외부파일형태의 binary의 경우가 잘 지원 안되는 경우도 있었습니다.(제 경우 크리스탈 리포트에서 사진정보를 외부파일에서 가져오는 것이 불가능하여 외부 파일을 BLOB로 속여주는 꽁수를 썼었습니다.)

또 외부파일 형태로 하시고 BFILE 인터페이스를 제공하는 것도 방법입니다.

각설하고 저는 가능하면 DB에 넣는 주의입니다.뭐 이유는 간단합니다.

디비 어플리케이션과 관련한 파일 처리는 반드시 디비의 다른 부분과 어떤 형태든 관련을 맺습니다.그렇다면 디비에서의 접근가능성이 높은 쪽이 어떤 알지 못하는 문제가 발생하였을 때 해결할 수 있는 가능성이 더 높다고 봅니다. 또한 디비에 들어가 있는 놈을 파일로 속이는 일이 그 반대의 경우보다는 더 쉽습니다.마지막으로 동일한 일을 할 수 있는 여러가지 방법이 있다면 ... 가능한 한 그 방법의 가지수를 줄이는 것이 시스템의 복잡도를 떨어트릴 수 있는 방법이 됩니다.이 외에도 많겠지만(관리적 측면이나 ... 등등) 개발자 입장에서는 가장 중요한 것이 문제 해결을 쉽게 하는 것이기에 제 생각은 이렇습니다.

Clob을 쓰시는게 좋을듯 합니다. 백업 과정에 자동으로 포함된다는 장점도 존재하며...

Intermedia Text로 본문 검색 기능등도 구현이 가능하다는 장점이 있습니다.

Lob Type을 지원하지 않는 언어는 아직 못본것 같네요. MS에서 제공하는 ODBC드라이버나 아주 오래된 언어가 아니라면 이 부분은 문제가 없습니다.

다만... SQL문에서 무심코 "*"를 포함하시는 경우 성능 저하를 경험할 수 있습니다. 반드시 필요한 컬럼만 나열하시고... 본문이 필요치 않은 경우 Lob Type컬럼은 빼시는게 성능에 좋습니다.

예를 들어...

select id, name, title from board    (o)

select * from board (x)     <--- 이 경우 본문을 위한 Lob Type이 필요치 않음에도 Fetch시 포함되므로 오버헤드를 유발함.