Naming convention for automated table outputs (processed with Python)

automationnaming conventionoracletable

I have several tables that I process nightly with Python.

For example, I have read-only access to an incidents table. I process the table with a specialized Python library called ArcPy. The script has a number of steps, including calculating the Minimum Bounding Geometry (a.k.a. convex hull) of like-incidents. The script processes the incidents table nightly and outputs the results to a new table.

I would like to follow database conventions and industry practices when outputting these tables, where possible. Having a distinct naming convention would allow me to easily identify master tables from output tables.

Is there a naming convention for automated table outputs (processed with python, or otherwise) that I should be using?

Best Answer

I dont think there are any hard rules around this. It's really up to you to decide what convention suits you best.

The options available to you may be influenced by the database software you are using.

The 3 suggestions i have are:

Use a different schema i.e [Processed] and keep the table name the same.
Add a prefix so that all processed tables appear together.
Add a suffix to the table name. So that when you sort by name the original and processed appear together.

The 2nd and 3rd option make more sense if you spend more time working with tables as groups or with original and processed as a pair.

Related Solutions

Should I use a Column naming convention or rely on column descriptions

Pick a standard, make sure it makes sense, and document it. There have been plenty of debates about this (e.g. whether the identity column in the contacts table should be called ID or ContactID, or whether the contacts table should be called dbo.Contacts or the unnecessarily verbose dbo.tblContacts), and you're never going to find agreement among your peers. Which standard you choose is not important; what is important is that you use it consistently, make it well-known, and get agreement from your colleagues that this is the way.
Your columns should be self-documenting (and not cryptic, abbreviated or obfuscated) where practical. I would NOT rely on the extended properties, but that's just me (google/bing for problems with extended properties and you will see plenty of complaints I would guess). External documentation / data dictionary is much more valuable to me - if your database goes south and so does your backup, it makes it that much easier to rebuild. It also makes it easier to describe your schema to junior developers etc. without giving them direct access to everything.

Naming a second additional column referencing another table column

You may consider that the breaking of the convention is actually indicative of an error or inefficiency in the design:

For example,

I would have a lookup table for this instead of two occurences of the same foreign key field in a table.

Product Table
------------
Id
Description

Product_Currencies Table
------------
Product_Id
Currencies_Id
Condition_Id

Condition Table
-----------------------
Id
Description

Currencies
------------
Id
Code
Description

In effect, the Product_Currencies table formalizes the relationship : Given this condition, use this currency for this product.

The condition table might contain values like:

Condition
ID     Description
----------------
1      Internal 
2      External

The naming convention being broken may be a symptom of a problematic design- many conventions are partially intended to cause issues when violated.

Having two Currencies_Code in one table implies conditional use, which may imply another relation is necessary to describe it.

If you must have an answer to the original question:

It's totally and entirely dependent on who enforces and/or codifies your standard.

Best Answer

Related Solutions

Should I use a Column naming convention or rely on column descriptions

Naming a second additional column referencing another table column

Related Question