Talk:Servoy Best Practices/Chapter 3
From ServoyFORGE Wiki
Contents |
[edit] unique names across modules
the first section gives a list of elements that must have unique names across all modules in use. Yet the recommended prefix is com_. Would it not make more sense to use a sol_ (or mod_??) prefix to ensure this uniqueness, rather than maintaining a mental list or reference of all global variables, forms, relationships, etc in other modules so as to not duplicate a name? kazar 14:45, 5 September 2010 (CEST)
True, in practice I tend to use the module name/prefix now --Wikiadmin 20:54, 5 September 2010 (CEST)
OK, changed to "sol". Now I'm wondering if the string "sol" should be replaced by "mod" throughout. Especially to the beginner (for whom I am perfectly and seemingly permanently qualified to speak) the whole "a module is a solution and a solution is a module" thing is confusing to begin with. But first we talk about names of objects needing to be unique across modules, then we name things with "sol" which to my neophyte mind indicates the name of the solution that will incorporate various modules. The uber-solution, IOW.
So. "sol_" or "mod_"?
ALSO, what about database connections: mod_db.connection.name?? kazar 10:28, 6 September 2010 (CEST)
[edit] indexes
hmmm. what about indexes? --kazar 02:12, 26 July 2009 (CEST)
The standard syntax for indices is tablename_columnname_idx but sometimes people also use the 'idx' as a prefix instead of a suffix Same for primary key indices "tablename_columnname_pk" or with 'pk' as prefix. --Wikiadmin 15:45, 5 September 2010 (CEST)
[edit] "utility" fields
i have begun to name columns that are really meta-data and not attributes (nor fk nor pk) like this:
pfx_u_insert_by
pfx_u_insert_dt
pfx_u_sequence
pfx_u_update_by
pfx_u_update_dt
this keeps all the utility columns in a group when sorted alphabetically --kazar 10:21, 26 July 2009 (CEST)
[edit] use "pk" for pk
there are some tables that will have one key attribute that already must be unique. for example, "contact_supertype" might contain: individual, organization, household.
it seems silly to generate a meta-value pk (e.g., a UUID or other unique string) when there is already this meaningful string. So long as update is checked on fk relations of course.
Therefore since the pk of a table may not always be a meta-value id string but rather might be a meaningful, unique attribute of the row, I include "pk" in the column name, e.g.:
pfx_pk_consupertype -- kazar 10:21, 26 July 2009 (CEST)
[edit] fk naming
i have started to use a more complex foreign key naming convention that indicates by simply reading it how the delete & update rules are set up.
For example:
The join table for contact ("con") to contacttype ("cty") is called con_contype ("ccy").
In contacttype the pk is a user-entered value (such as Vendor, Customer)
Obviously in the join table the delete rule is "cascade" and the update rule is "cascade"
foreign key name: [companypfx]_ccy_contacttype_cas_cas
I'm using:
No Action = no
Restrict = res
Cascade = cas
Set Null = nul
Set Default = def
for the standard pk (such as a UUID) to fk relationship that needs a cascading delete and no update, such as in an order-item table:
[companypfx]_oit_order_cas_no