CamelCase != ORACLE_CASE

 
This is as much a reminder as a ‘tip or trick,’ and the reminder is directed as much at ourselves as anyone.
 
A common tenet of modern software engineering is to use descriptive names for variables and fields. For example, if you have the need to store a transformer ‘s serial number you’d do well to create a field or variable named “SerialNumber”.  CamelCase_000Seems self-evident, but you may remember programmers who would use a name like “n1″ or “i1″ and argue it’s efficient — though deep down you knew it was about their view on job security.
 
It’s also common to use change in case to denote word separation. The technique is sometimes referred to as “Camel Case”… conjuring the hump image thing. You see it everywhere, including standard data models, a snippet of one you see to the right.
 
Thing is, some databases honor case and some don’t.
 
Below for example are tables created from the same Transformer UML model snippet, one in MS-Access and the other in Oracle. As you can see, once the names have been forced to upper case in Oracle our clever CamelCase convention doesn’t look so clever.

CamelCase_001

So, the point is this. When naming fields, do so with the end environment in mind. And if the end environment forces names to upper case, consider separating distinct words in field names with something like an underscore, so the thing you hoped would appear as “SerialNumber” but actually appears as “SERIALNUMBER” will in fact appear as “SERIAL_NUMBER”.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>