Hello Peter, welcome to Servoy world
psijmons wrote:We will be migrating a large FileMaker solution to Servoy in the coming years and have decided to build the servoy solution from scratch.
In preparation, we are cleaning up the ERD, table names and field names as these carry some historic mistakes and we have the opportunity now to clean that up.
While not very fluent yet in Servoy, some consequences of name covention decisions are not fully grasped and we may regret them in the future. I could not find the definite whitepaper on naming conventions so I would like to base the decisions on the servoy developer experience
Some guys on this forum already know my opinion to naming conventions and some have already given reference. So I only would like to say that keep in mind that naming convention are mainly used because of the Developmont Tools shortcoming, very often because grouping possibilities are missing. So they may be necessary in certain cases, but ususally they can confuse as much as help. I strongly would advice not to put type information and such into the naming convention because if they change, very often one forgets to also change the naming or it may be a real burden to do that. In short, one has to think about how a naming convention is intended to help (others, oneself, ...) and does it fullfill this requirements. Often one can find lot's of more or less consistently applied naming conventions in code, and I think that's more a hindering than a advantage. But of course you decide for yourself - good look in finding a useful solution! As said, that is may opinion only and can be way off others. Our rule is use only when really needed and an obvious advantage results from it's use. Because in the end, you also have to manage ALL your pre- and postfixes ...
psijmons wrote:Primary and foreign keys
The convention we used in the FM solution was __kp_Contact and _kf_Contact. This was useful as these fields sorted on top when making connections in the ERD and selecting fields in the script manager. As there is no ERD in Servoy, the double and single underscores may become a nuisance when typing in JavaScript and the key fields should be changed to e.g. contact_id
Is it useful to make a distinction between the primary and foreign key as the underlyng table is always visible in JS ?
We don't use any prefix for a pk, as it's alway clearly visible in either a Datamodelling tool (Design time) or in Servoy (Implementation). For an artificial key (with a sequence), we always use the attribute/column name "id". Concatenated keys are just built up from their "native" names, like for a (school) class this could be level, sign, schoolYear, fractionName as attribute names and level, sign, school_year, fraction_name as column names.
The only convention we use is for foreign keys. They are built up like: <related entity name>_<related pk>.
For example you have a 1:m relationship form orders to order_positions (where the pd of table orders is id), the foreign key in table order_positions would be order_id (always use the (singular) entity name for the prefix, not the plural).
Or, as a second exampel, for (school) classes having 1:m class_members, where class is having the above mentioned pk's, the foreign keys would be class_level, class_sign, class_school_year, class_fraction_name.
This is approach also guarantees uniqueness for the foreign key namings.
Entities should be named singular (as they are Entity Sets), and tables plural. In Entities you may use camel case (recommended), whereas in tables use underlines (for compatibility).
psijmons wrote:CamelCase vs underscores
are there still SQL databases that ONLY allow lowercase field names or are CamelCase now widely accepted ?
I realize there are no fixed standards here (the servoy sample for instance mixes plurals and singulars) so I'm more interested in best practices from the Type Ahead point of view as this will have a lasting effect for years to come.
TIA,
Peter
See above, Servoy itself does not in any case support camel case, like for calculations, when using camel case and want to make it a stored column means problems .-o
Best regards, Robert