Re: Help, my developers are killing me with varchar2(4000)

On Aug 15, 4:08 am, Noons <wizofo..._at_yahoo.com.au> wrote:
> DA Morgan wrote,on my timestamp of 15/08/2008 11:17 AM:
>
>
>
> >>> So what should the default size of a varchar2 be then?  7?  12?  23?  0?
>
> >> does it really matter?  it's variable length anyway:
> >> the size is a constraint, not an allocation issue.
>
> > As with many things ... depends ...
>
> > For example when working with bind variables VARCHAR2s are rounded to
> > the next highest length that can be 32 bytes, 128 bytes, 2000 bytes,
> > or 4000 bytes.
>
> I don't think VARCHAR2s are rounded up at all in the
> tables, which is what I thought we were talking about.
> Sure: a bind variable might "adjust" the length of a
> VARCHAR2 parameter, but that does not replace the table
> column's definition in the dictionary?
>
> IOW: the bind variable might not store data very efficiently
> but the column in the table doesn't stop having its max
> size checked because of that?

The OP asked if it is a bad idea to design tables with everything 4000 long varchar2's, so part of the answer is going to involve what happens when you move the data out of the db and manipulate it. Does the size definition make a difference in how Oracle deals with the data? Yes, it does. Is it a big deal? Well, to answer that, you have to define what a big deal is.

Whatever definition you come up with, if you start investigating what happens under high load, it becomes a big deal. That's where most of these developers that create generalized solutions fall short, since they assume you can always throw more hardware at it and it will magically scale, without specifying an upper limit requirement. Right?

jg

--
@home.com is bogus.
Mommy, why are they arresting Tinkerbell?
http://edition.cnn.com/2008/US/08/15/disney.protesters.ap/index.html?iref=mpstoryview