Database Naming Conventions.

Whilst everybody has their own database naming conventions, we recommend using snake_case as it is more readable - especially for people of foreign languages.

The naming of the fields echoes throughout the generated code and is a recommended way of keeping things consistent. That being said, there are no reasons that camelCase naming conventions will not work, however this is untested.

We also recommend that each field is prefixed with it's type, as listed below. This may not be a complete list, however it has stood us in good stead.

Important!

Each table that is generated MUST contain a primary key of type bigint.

Why?

There is nothing worse than having a table which doesn't have a unique primary key, apart from one which is called id. Plenty of times in the code we will be using multiple primary keys from all sort of tables, so we end up littering our code with object.getId(). Rather than having to distinguish between the different id variables, we like to know what primary key it is referring to. (And with the 'extract to local variable shortcut in our IDE - it means that the variable is named appropriately).

For example:

object.getIdPet() will give us a completion of Integer idPet = ..., and we __ALWAYS__ know that this is a unique identifier to a Pet in the database, no matter where it comes from.

Suggestions for field names

prefixmeaning
id_Primary key usage and unique identifiers. In the case of a primary key for a table, the recommended field name is id_<table_name>
txt_For textual representations
nm_Proper names for fields, e.g. nm_person, nm_country
num_Numbers (integers/bigints)
fl_Flags - i.e. boolean types - should always be of type tinyint(1)
cd_Codes for the data - i.e. cd_postcode
flt_Floating point values.
dbl_Double precision values
tm_Time values
dt_Date values
ts_TimeStamp values

And whilst not actually required, this will help with the code generation and keep it consistent throughout the code.