The Old Joel on Software Forum: Part 4 (of 5)

Field Name ?

What would you have done if you join the group with such naming conventions for fields in the database? How one can address such issue ? Or it is not the issue any longer, since MS let you name field without size restriction. ?

Here is an extract from the code :

<<

where
dbo.HouseMarginRequirements.CloseofBusinessDatemarginableSettlementDateNakedoptions
= dbo.ClientResources.MarginSettingBaseDate

>>

LI
Friday, April 30, 2004

where
dbo.HouseMarginRequirements.
CloseofBusinessDatemarginableSettlementDateNakedoptions = dbo.ClientResources.MarginSettingBaseDate

LI
Friday, April 30, 2004

SELECT Gun From Safe
WHERE (Programmers = Masochists)
INNER JOIN On DrinkingClub (Booze = NumbPainOfExistence)

Infinite Monkeys
Friday, April 30, 2004

You know, those may be a pain to type, but anyone knows immediately exactly what those columns mean. They're a lot better than:

where dbo.t1.f32 = dbo.t2.f33

Use a drag&drool designer to build the select statements and relax a bit. :-)

Chris Tavares
Friday, April 30, 2004

oooo... you have a drag & drop designer for stored procedures?

Philo

Philo
Friday, April 30, 2004

no for SP's we have .... notepad and ctrl-c, ctrl-v

The Artist Formerly Known as Prince
Saturday, May 1, 2004

"You know, those may be a pain to type, but anyone knows immediately exactly what those columns mean"

bingo. Personally Id thank all the gods that they didn't make the decision to go:

dbo.HMR.CBDSDN=dbo.CR.MSBD

because you just know that somewhere else they will have used:
dbo.HMR.CBDSND=dbo.CR.MSBD

I operate on the theory of "better long than opaque"

besides, every field name is just a control-c, control-v away.

Maybe you should write a wee app that displays a window containing all the field names in a list, allowing you to list by table and type, and copy n paste very quickly into your working code.

shouldn't take more than an hour or two and could save you a lot of pain.

FullNameRequired
Saturday, May 1, 2004

oooo... you have a drag & drop designer for stored procedures?:

I do, in Visual Foxpro, unfortunately it throws its fruitcake up if its gets more than a little complicated. But at least I can get a halfway sensible query which I can then edit and clean up the peculiar order of inner join syntax it likes.

And no, I'm not limited to using it with native Fox tables but with anything you can connect to as an ODBC or ADO connection. And yes, that means I can store them as stored queries on SQL Server.

Problems may arise with extremely lengthy field names and limits on the size of a query statement, depending upon the client and connection. An alternative approach to pushing the system limits on field names is to have sensible field names and use something like a Caption property (if its available in your particular DB) which can be used both as the default caption on forms and as documentation of the field.

Simon Lucy
Saturday, May 1, 2004

OK
I see opinions are different about using such long names. I would really preferred to use much shorter meaningful names , no longer than 10 -12 char. And even with such long names at least underscore would be useful.
I really do not understand the naming conventions, since some words have first letter capitalized, some not.
The truth is people who develop this awful database are very amateur developers and long names – is just a tip of the iceberg.

LI
Saturday, May 1, 2004

autocomplete is your friend. long names? who cares. control-space will type it for you, and correctly, and with a few options if there are similar names.

the only drawback is readability, sometimes names are so long you can't see the bigger picture because it now takes 10 pages.

mb
Sunday, May 2, 2004

I don't mind long, camel-case names - the point that they are more or less self-explanatory is valid. I do try to make them a bit shorter, though...

What I HATE is the convention of using all caps for database entities, i.e.

SELECT NAME FROM USERS WHERE (...)

I find that atrociously unreadable. Can anyone point out the pros for this convention? I sure can't...

MediocreDev
Sunday, May 2, 2004

I hate underscoring. I find CamelCase as being the best for field names.

We can't tell from the example whether the developers were good or bad. The problem with abbreviated or semitic script as in NkdOptns is that you have to remember the abbreviated form you use.

Stephen Jones
Monday, May 3, 2004

that would be NakedOpticians

Simon Lucy
Tuesday, May 4, 2004

CamelCase maybe better than CmlCase.
I am talking about 40 and longer char words. How readable and useful to have such field names?
It is not just matter of using copy and paste.

LI
Tuesday, May 4, 2004