Skip to Main Content
  • Questions
  • Why use inline CLOBs over a varchar2(4000)?

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, John.

Asked: July 06, 2004 - 10:06 pm UTC

Last updated: July 22, 2004 - 10:59 pm UTC

Version: 9.2.0.5.

Viewed 1000+ times

You Asked

Tom,

Why use inline CLOBs over a varchar2(4000)?

An inline LOB is for data under 4000 bytes in length. Why have inline LOBs when we can use varchar2? Wouldn't you rather just create a varchar2(4000)? It seems like less maintenance and more user-friendly to just use varchar2(4000).



and Tom said...

what happens when you need 4001 bytes stored?


you use a varchar2 when the data will never exceed 4000 bytes.

you use a clob when the data will perhaps sometimes exceed 4000 bytes.

Under 4000 bytes, a clob works very much like a varchar2.
But, unlike a varchar2 -- it does not stop at 4000 bytes - it goes and goes and goes (and grows)



So, if you have LESS THAN 4000 bytes to store, use a varchar2, by all means. A clob would not be appropriate.

If you have MORE THAN (possibly more than) 4000 bytes - you use a clob.

Rating

  (6 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

John Cantu, July 07, 2004 - 5:55 pm UTC

Understood! Thanks Tom.

The right question is

Mikito, July 08, 2004 - 12:08 pm UTC

When oracle would fix its String implementation?

Every modern programming language allows strings of variable lengths so that programmer pays little attention to character string space management. And look into CLOB. The whole documentation volume dedicated to a single datatype! That looks ridiculous.

AFAIK, Microsoft VARCHAR has unlimited bound.

Tom Kyte
July 08, 2004 - 12:24 pm UTC

check facts (it was easy to verify)

MS has a varchar type and a Text type (guess what text is?)

</code> http://www.winnetmag.com/SQLServer/Article/ArticleID/26852/SQLServer_26852.html <code>

hmm, the "text in row concept". imagine that? what -- three types i guess from MS.

and the programmer that pays little attention to details like string space management is the programmer who's code a I rue.

An entire document dedicated to a datatype designed to store gigabytes of information (hey, yeah, lets use the modern language java and do things with gigabyte strings -- oh wait, we might need to think about that might'nt we)


give me a break mikito.

please commit harakiri mikito

A reader, July 09, 2004 - 3:34 am UTC


Learn abstraction

Mikito, July 09, 2004 - 1:24 pm UTC

So if your text string is small, then you just can haver its value in the client program. If the string is big you have to stream it. And if it's insanely big then I have to pray?

Obviously, you have to be politically correct in your reply (never heard of politically incorrect VPs), but this is just a lame excuse for oracle not making an obvious enhancement.

Tom Kyte
July 09, 2004 - 1:54 pm UTC

nothing is obvious.  I think people have seen that I say what I think.

a little fact checking would verify that fact out.  (again with the fact checking)


SQL> set ignore on;

 

Time to Move On Mikito

Just Another Reader Sick of Incoherent Ramblings, July 09, 2004 - 2:40 pm UTC

Apparently you are very fond of Micro$oft - why not haunt their forums? In case you haven't noticed, people here are getting tired of your trash. As far as being PC is concerned, you apparently don't care who you offend so since you aren't getting any support for your dogma here why not go elsewhere? Then the rest of us can get on with the task of learning more about Oracle so we can be better prepared to manage it.

A reader, July 22, 2004 - 10:59 pm UTC

Tom

What the issue with this Mikito Dude.. he seems to be anti Tom ?

More to Explore

CLOB/BLOB/etc

Complete documentation on Securefiles and Large Objects here