topic Re: Feature Class Naming Convention: Singular or Plural in Data Management Questions

Feature Class Naming Convention: Singular or Plural

RandyKreuziger — Mon, 06 Oct 2014 23:44:41 GMT

After over 20 years of being cowboys my agency has finally decided they want one standard shared by both the traditional business side and the GIS side. Our business database developers have use and argue for all table names to be singular. When looking at the wild west, aka GIS folks, I see a combination between using singular and plural in feature class names. I understand the needs for standards but non-GIS databases are hidden behind user interfaces and application where as most of our users are looking straight at the data in ArcMap / ArcCatalog. Some feature class names just sound more natural using the plural like Cities vs City.

What are others doing for feature class naming conventions?

Re: Feature Class Naming Convention: Singular or Plural

OwenEarley — Tue, 07 Oct 2014 22:43:55 GMT

Personally, from a GIS perspective I think it makes way more sense to use the plural form as the feature class/table is a collection of objects. However, for database developers it often makes more sense to use the singular version - for example:

Singular:

SELECT City.Name FROM City WHERE City.ID = 42

Plural:

SELECT Cities.Name FROM Cities WHERE Cities.ID = 42

In this context the singular table name makes more sense to me. However, as you correctly point out in most cases this detail is totally hidden from the end user. Also, most modern development uses Object Relational Mapping (ORM) that abstracts away the raw SQL code and would let you have a table named Cities but work with properties such as City.Name for your objects.

Out of interest, Microsoft's Entity Framework creates plural table names by default.

Either way at least your agency is developing a single standard.

Re: Feature Class Naming Convention: Singular or Plural

OwenEarley — Tue, 07 Oct 2014 22:54:02 GMT

And you can tell your database developers:

you must be a pirate for the pirate's code to apply..., and the code is more what you'd call "guidelines" than actual rules (Capt. Barbossa)

Re: Feature Class Naming Convention: Singular or Plural

RobRader1 — Tue, 07 Oct 2014 23:41:24 GMT

I think it is much more important to agree to all upper case table names and removing underscores from table names. Those type of standards can stick. One standard for the Object Name in the database and another standard for the business names in Aliases and Layers is also normal.

Object Naming: Many customers I have worked with use the singular for a table name and multiple in the case of a feature class. A single point on a map can often represent more than one business unit.

E.G. Transformers with a 1:M relationship to a table named Transformer Unit

That said, it is all configurable now. You can always alias or create layer names for the end users to see.

Re: Feature Class Naming Convention: Singular or Plural

OwenEarley — Wed, 08 Oct 2014 01:13:55 GMT

I much prefer Pascal case for table names as it is easier for users to read - for example:

CITYPARKS
CityParks

Re: Feature Class Naming Convention: Singular or Plural

DanPatterson_Retired — Wed, 08 Oct 2014 07:25:06 GMT

Wow..."... Our business database developers have use and argue for all table names to be singular..." must be such a sad place to work...or humorous

I will continue to use Mathematics, Rhetorics, scissors, short, series, news, headquarters, civics blues and billiards and they must have one H of a time identifying the singular from the plural in this list bison, buffalo, deer, duck, fish, moose, pike, plankton, salmon, sheep, squid, swine, trout ... Me thinks they are getting their "trouser" in a tizzy

I pray that Geographers, Geomaticians and Cartographers continue to rail.... È contro questo che volete inveire.

Re: Feature Class Naming Convention: Singular or Plural

RobRader1 — Wed, 08 Oct 2014 20:09:45 GMT

I agree that it is easier on the eyes, but that is where I would lean towards the alias being Pascal and the actual table name being all upper.With the fact that databases can be case sensitive now for table names, it makes mixed case a bit of a problem for programmers and sql developers alike.