Naming convention for scheduled geoprocessing outputs

Question

I'm planning on implementing several geoprocessing python scripts that are scheduled to run nightly. The scripts will either output new feature classes, or update existing ones. The environment is an Oracle geodatabase.

I find with other database objects, it's helpful to be able to easily differentiate between object types, sources etc. in ArcCatalog (or other database software). Examples would be:

• Feature classes and non-spatial tables have different icons in the catalogue tree
• Specialized geodatabase objects have unique icons
• Views are suffixed with _VW (best practice)
• Versioned views are suffixed with _EVW

However, when it comes to scheduled geoprocessing outputs, I'm not aware of any way to differentiate them from regular feature classes at first glance. Sure, metadata is an option, but I'm looking for something a little more in-your-face than that.

Is there any sort of naming convention that is used for scheduled outputs? Maybe suffixing the table with a _GP (for geoprocessing) or _NT (for nightly task)?

---

For example:

I have read-only access to a non-spatial INCIDENTS table from 3rd party software. The table has X and Y columns. I have a geoprocessing script (scheduled nightly task) that processes the table. It creates XY event layer, does a spatial join, and outputs minimum bounding geometry. In other words, the output is a copy of the original data; the only difference is that it has been processed.

I'm looking for a way to identify geoprocessed copies of data, such as the example mentioned above. It would help us administrators easily keep track of which tables are master tables, and which ones are copies.

It could be something as simple as a _COPY suffix. Or maybe there are established database best practices/conventions.

Answer 1

I do not believe there is a standard naming convention for explicitly identifying tables created through automated processes (whether it's stored procs, geoprocessing, scheduled tasks). See What standard should I follow when naming tables and views? on DBA Stack Exchange. Because there is no Standard, many organisations create their own database naming convention policy.

Because of this your suggestions of _gp or _nt would work, if you are consistent! That said, I'll put a bit of my experience and what I found on some other sites.

Stack Overflow has a handful of Q&As where users have asked for naming conventions for databases. None of the ones I found mentioned automated processes at all. There is also a lot of opinion or preference (or habit) mentioned, and very little actual standard involved.

I found some of the answers to Database, Table and Column Naming Conventions to be quite useful (and familiar). I also found a couple of documents^{1, 2} from different organisations with their own naming conventions (which were very similar despite being different organisations). Yet it is just as easy to find other pages³ with naming conventions which were very different/opposite to others.

I'll few points here that together could be used as a basis for naming your processed tables.

• PascalCasing (rather than underscores) - MyFeatureClass rather than My_Feature_Class
• Schema naming - gisdata.MyFeatureClass
• Views prefixed with vw in order to group them together - vwMyFeatureClass
• Name the table based on what it contains.

From those points you could put together your own naming convention. Here are a couple of my suggestions to consider:

• gpMyImportTable - using a prefix for processed data. This will group these together when looking through tables.
• geoprocessed.MyImportTable - using a separate schema for processed data. This will also group them together, but also gives the advantage of having a specific name that's not interrupted by a prefix
• MyImportTableCopy - Name it what it is, a copy of your table, identifying it as a copy in the name. If it's not a copy, but a modification, you would use a different word like MyImportTableModified. (I am not a fan of this option)

In an organisation I used to work for, any data that came in from a non-spatial database had a different schema so they were obviously not originally a geodatabase table.

geodatabase.MyFeatureClass
geodatabase.MyOtherFeatureClass
geodatabase.NonSpatialTable
geodatabase.vwSomeView
diffdb.OtherTable
diffdb.ThirdPartyTable
diffdb.vwViewFromExternal

---

<sup>1. SQL Server Naming Standards
2. Database Administration SQL Server Standards
3. How I Write SQL, Part 1: Naming Conventions</sup>