RE: : RE: bytes vs chars

From: Robert Freeman <rfreeman_at_businessolver.com>
Date: Mon, 14 Mar 2016 19:57:28 +0000
Message-ID: <BY2PR10MB0744127C1963B6F2556EE292D5880_at_BY2PR10MB0744.namprd10.prod.outlook.com>

Guessing at how big or small to make a VARCHAR or just making it as big as it will go.... Guessing at which character set to use... These kinds of problems are all the classic hallmarks of not getting things right from the beginning.

I've seen it so many times. Requirements not well understood or poorly defined. Agile becomes fragile, iterations spinning out of control. Object Oriented design becomes the be-all end-all of everything. Sometimes it's an inexperienced DBA staff fails to properly articulate not only what best practices are but WHY we do things the way we do. Then, there are the many times when DBA's are just left out of the development process until the 11th hour when everything is about to fall over.

I'm amazed at how many DBA's themselves cannot articulate why we build things in 3NF - which leaves developers (and a fair number of managers) with either object oriented minds or 3GL thinking processes to argue about database designs and often win (or they just do the designs and nobody pushes back) - Thinking in rows sets? Heh, they think in terms of their most complex Excel spreadsheet. They live for loops with commits everywhere, and a host of other naughty things that kill performance.

These results tend not to lead to optimized database designs - to be kind.

And they wonder why the beast performs badly... oh look! Your rows span more blocks than there are grains of sand in the samarkind desert...

Root cause... bad bad bad development processes, bad management and perhaps - DBA's who need to be less abrasive and more articulate? Maybe we need to spend more face time than Facebook time? How often do you get out and press the flesh? (from one who confesses his social skills are less than stellar.

What is it that Smokey DBA said - Only you can prevent bad database designs.

Oh - I could go on and on... so much evil is had at the beginning that if corrected, could avoid unpleasant experiences towards the end.

RF

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Neil Chandler Sent: Monday, March 14, 2016 12:57 PM
To: oracle_at_1001111.com; Oracle-l <oracle-l_at_freelists.org> Subject: RE: : RE: bytes vs chars

Sometimes I wonder if these emails are sent just to wind me up, but there is an important reason why you should not just define VARCHAR2 columns really large "just in case".

Should the definition of a table approach or exceed the size of your Oracle block (so in most cases around 8k), Oracle will no longer be able to perform set-based operations against the table. This will significantly increase the redo requirement, and cause performance problems. <<snip>>

Neil Chandler
> To: oracle-l_at_freelists.org<mailto:oracle-l_at_freelists.org>
>
> Why are you even worrying about it.
>
> Make it VARCHAR2(255) or VARCHAR2(1000) and save yourself resizing it AGAIN in the future.
>
> IMHO
> Dave
>

--
http://www.freelists.org/webpage/oracle-l

Received on Mon Mar 14 2016 - 20:57:28 CET