TOPIC: Table/Field Naming Practices?
Table/Field Naming Practices? 11 Months ago
I am wondering what is the common practice for creating table names and field names? For instance, say I want to track aircraft engine types and aircraft. aircraft engine types contains just one field, name. aircraft contains say, make, model, engine_type and comments.

What would be your suggestion for naming? I see some that would make:

"aircraft_engine_types (aet_name)"
"aircraft (a_make, a_model, a_engine_type, a_comments)"

Is that better/more desired than:

"aircraft_engine_types (name)"
"aircraft (make, model, engine_type comments)"


Re:Table/Field Naming Practices? 11 Months ago
Our standard is to use an abbreviation of the table name as a prefix of the field names.

We also go a step further and add an abbreviation of the "module" as a prefix of the table names.

One exception is when a field is a "foreign key" i.e. it references a key in another table. In that case we use the name from the other table.

One of the reasons for both of these is to make it easier to join tables. Suneido automatically joins by common field names. The prefix avoids unintentional join fields. (You can always work around this by using rename along with join.)

Note: We use the new "join by ..." specification on our queries. It's not required but it's a good check that queries are actually joining on the fields you intend.

NOTE: The system tables and stdlib were written prior to adopting these rules so they don't follow them very well.
Re:Table/Field Naming Practices? 11 Months ago
When you do, say,


ensure aircraft (a_tail_no) key (a_tail_no)
ensure logbook (l_created_at, ..., a_tail_no) key (l_created_at)

How do you handle the fact that when in browsing/accessing the aircraft table that a_tail_no should be a Field_string, however when browsing/accessing the logbook table that a_tail_no should be a IdControl?

Re:Table/Field Naming Practices? 11 Months ago
We would rename one, usually the "main" one on the assumption that there are more secondary references. Then you can have a different Field_ definition (probably one inheriting from the other)

For example, the Access/Browse on aircraft would actually be on "aircraft rename a_tail_no to a_tail_no_new"

This also allows attaching a rule in one place but not another.

It's a little ugly, but it works.