Column naming conventions?

Posted by teppo_55 on 07-Sep-2017 08:24


Of course we all use strict naming conventions for reference keys: like employee.employeeId (never: employee.id).
But now the question:
Should You use
a. employee.employeeDescription
b. employee.employeeDesc
OR
c. employee.description
?

All Replies

Posted by jmls on 07-Sep-2017 08:26

c.

everytime. It drives me *nuts* looking at code that has the tablename as part of the fieldname.

Posted by Scott Riley on 07-Sep-2017 08:53

Why would you record a description of an employee? Is this just in case you needed to describe them to the police?

Posted by Peter Judge on 07-Sep-2017 08:56

I agree with Julian.
 
An child tables/relation should include the parent name though
Benefits.EmployeeId
 

Posted by Mike Fechner on 07-Sep-2017 09:20

Looking nice.

Sent from Nine

Von: Peter Judge <bounce-pjudge@community.progress.com>
Gesendet: 07.09.2017 15:57
An: TU.OE.General@community.progress.com
Betreff: RE: [Technical Users - OE General] Column naming conventions?

Update from Progress Community
Peter Judge

I agree with Julian.
 
An child tables/relation should include the parent name though
Benefits.EmployeeId
 

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

Posted by jmls on 07-Sep-2017 09:29

meh. Benefits.employeeId ;)

Posted by danielb on 07-Sep-2017 18:47

For this particular example, I would go with (a). It's good practice to avoid having Progress keywords as schema names (in either table or field names)

Posted by teppo_55 on 08-Sep-2017 00:24

 
The arguments to coinsider are:
  • Avoid shortening
  • Easiness to read (in code we always write table name, like employee.description)
  • Appertains to fields without relations (like description, startDate, endDate)

 

? Can/should we use field names without rerefence to table name ?
? What about rule of two-piece field name (employee.description vs. employee.descriptionText) ?
 
 
Regards
 
  • teppo
 
 
--------------------------|--------------------
Teppo Määttänen____| TR-Tiimi Oy
Consultant_________| Struerintie 1
teppo @ trtiimi.fi____| 30100 FORSSA
int-358-50-5748 226   |
www.trtiimi.fi
--------------------------|--------------------
 
Lähettäjä: Peter Judge [mailto:bounce-pjudge@community.progress.com]
Lähetetty: torstai 7. syyskuuta 2017 16.57
Vastaanottaja: TU.OE.General@community.progress.com
Aihe: RE: [Technical Users - OE General] Column naming conventions?
 
Update from Progress Community
 
I agree with Julian.
 
An child tables/relation should include the parent name though
Benefits.EmployeeId
 

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

 



AVG logo

This email has been checked for viruses by AVG antivirus software.
www.avg.com


Posted by Mike Fechner on 08-Sep-2017 00:32

descriptionText? Really? What else should it be?
 
Imho you should not turn off common sense when following conventions. A description implies text, there may be multiple descriptions: ShortDescription, LongDescription.. Unless it’s a reference to a description stored in another table. In that case, I’d go with descriptionRef or descriptionId/descriptionGuid.
 
 

Posted by Akshay Guleria on 08-Sep-2017 00:49

Agree with Julian and Peter both. But lets also consider the way table is named (if you're interested :-) ). In your example the name of table is employee (singular form). It would be better to name it as `employees` if you think from the point of view that the table is supposed to store records of many employees (not employee).

So reading queries also makes sense with this convention. Like

FOR EACH employees NO-LOCK WHERE employees.id <= 20:

  // do something

END.

Moreover your "arguments to consider" seems good enough if you haven't had any coding conventions being followed in your team yet.

There is a GitHub page about OE coding standards which provide decent guide lines -> github.com/.../oestandards

Posted by Riverside Software on 08-Sep-2017 01:36

The debate over plural or singular in table names isn't new: stackoverflow.com/.../table-naming-dilemma-singular-vs-plural-names

My personal preference goes to the singular form, as typing "for each customers" just seems wrong to me...

Posted by Mike Fechner on 08-Sep-2017 01:44

Agree with Gilles.
 
FIND FIRST Customers . or FIND FIRST Customer ?

Posted by Stefan Drissen on 08-Sep-2017 03:09

Which is why there are tables and buffers. The table is plural, the buffer is singular.

define buffer customer for customers.

find first customer.

Unfortunately Progress gave us a default buffer which leads to all the confusion.

Also in the case of for each, it should be singular:

for each customer where ....
end.

The plural name makes sense when working on the records as a result set, as our SQL friends do:

select * from customers.

Posted by Riverside Software on 08-Sep-2017 03:22

> Which is why there are tables and buffers. The table is plural, the buffer is singular.

Is that worth a SonarQube rule ? :-)

Posted by Stefan Drissen on 08-Sep-2017 03:25

We have lots of tables with names which needed to fit in a limited number of characters for DB2/400 or so, so it wouldn't help. :-)

Posted by marian.edu on 08-Sep-2017 03:44

Basically all tables are somehow bound to store multiple records so why bother using the plural… you might think there could be just the ‘god’ table that only have one (true) record but in practice there can be zero or more records even there ;)


Have to agree that sometimes I use plural just to avoid conflicts with a keyword (both 4gl and sql) so ‘users’, ‘roles’, etc… if you’re fun on naming conventions, those are just exceptions (mine is more like French, full of exceptions).

Bref, forget about naming conventions and just use common sense. Since we’re referring a property of one object there is no point in keep repeating the object name when referring to it’s properties (employee.firstName, employee.lastName, …) as a side effect the developers will sometimes be forced to fully qualify the table name which in my book is a good practice anyway.
  
Marian Edu

Acorn IT 
+40 740 036 212

Posted by Patrick Tingen on 10-Sep-2017 06:29

You could also consider using the table name als the id field. In case of employee, the identifying field would be 'employee', so in other tables you would end up with something like 'benefit.employee'.

We don't use this convention ourself btw

This thread is closed