Using CLOB data type - Pros and Cons

Question

Dear Gurus,
We are designing a database that will be receiving comments from external data source. These comments are stored as CLOB in the external database. We found that only 1% of incoming data will be larger than 4000 characters and are now evaluating the Pros and Cons of storing only 4000 characters of incoming comments in VARCHAR2 data type or using CLOB data type.
Some of the concerns brought up during discussion were:
- having to store CLOBs in separate tablespace;
- applications, such Toad require changing defaults settings to display CLOBs in the grid. Default value is not to display them;
- applications that build web page with CLOBs will be struggling to fit 18 thousand chararcters of which 17 thousand are blank lines;
- cashing CLOBs in memory will consume big chunk of data buffers which will affect performance;
- to manipulate CLOBs you need PL/SQL anonymous block or procedure;
- bind variables cannot be assigned CLOB value;
- dynamic SQL cannot use CLOBs;
- temp tables don't work very well with CLOBs;
- fuzzy logic search on CLOBs is ineffective;
- not all ODBC drivers support Oracle CLOBs
- UNION, MINUS, INTERSECT don't work with CLOBs
I have not delt with CLOB data type in the past, so I am hoping to hear from you of any possible issues/hastles we may encounter?

Answer 1

848428 wrote:
Dear Gurus,
We are designing a database that will be receiving comments from external data source. These comments are stored as CLOB in the external database. We found that only 1% of incoming data will be larger than 4000 characters and are now evaluating the Pros and Cons of storing only 4000 characters of incoming comments in VARCHAR2 data type or using CLOB data type.
Some of the concerns brought up during discussion were:
- having to store CLOBs in separate tablespace;They can be stored inline too. Depends on requirements.
- applications, such Toad require changing defaults settings to display CLOBs in the grid. Default value is not to display them;Toad is a developer tool so that shouldn't matter. What should matter is how you display the data to end users etc. but that will depend on the interface. Some can handle CLOBs and others not. Again, it depends on the requirements.
- applications that build web page with CLOBs will be struggling to fit 18 thousand chararcters of which 17 thousand are blank lines;Why would they struggle? 18,000 characters is only around 18k in file size, that's not that big to a web page.
- cashing CLOBs in memory will consume big chunk of data buffers which will affect performance;Who's caching them in memory? What are you planning on doing with these CLOBs? There's no real reason they should impact performance any more than anything else, but it depends on your requirements as to how you plan to use them.
- to manipulate CLOBs you need PL/SQL anonymous block or procedure;You can manipulate CLOBs in SQL too, using the DBMS_LOB package.
- bind variables cannot be assigned CLOB value;Are you sure?
- dynamic SQL cannot use CLOBs;Yes it can. 11g supports CLOBs for EXECUTE IMMEDIATE statements and pre 11g you can use the DBMS_SQL package with CLOB's split into a VARCHAR2S structure.
- temp tables don't work very well with CLOBs;What do you mean "don't work well"?
- fuzzy logic search on CLOBs is ineffective;Seems like you're pulling information from various sources without context. Again, it depends on your requirements as to how you are going to use the CLOB's
- not all ODBC drivers support Oracle CLOBs not all, but there are some. Again, it depends what you want to achieve.
- UNION, MINUS, INTERSECT don't work with CLOBsTrue.
I have not delt with CLOB data type in the past, so I am hoping to hear from you of any possible issues/hastles we may encounter?You may have more hassle if you "need" to accept more than 4000 characters and you are splitting it into seperate columns or rows, when a CLOB would do it easily.
It seems as though you are trying to find all the negative aspects of CLOBs and ignoring all the positive aspects, and also ignoring the negative aspects of not using CLOB's.
Without context you're assumptions are just that, assumptions, so nobody can tell you if it will be right or wrong to use them. CLOB's do have their uses, just as XMLTYPE's have their uses etc. If you're using them for the right reasons then great, but if you're ignoring them for the wrong reasons then you'll suffer.