How is table.table less confusing than table.id?
We mean table.table_id which has clarity and reduces conflicts which can result from identically named fields in differing tables
I see what you mean. But still you have the alias (AS) clause for that which is the SQL formal way of disambiguating columns if needed.
Using just “id” was an SQL anti-pattern some time ago I am aware. And in some cases it is still considered as such.
You still have to type the table name one more time which is unproductive which is not DRY(although in DB context sometimes DRY is not the best approach).
However, this is not the main reason I am against anything that is not id. When you start integrating your database with other software some will give you the option to define what your PK column name is. But others are hard opinionated and expect an id column as your PK.
Bad or worse practice using “id” as your PK is reasonable and expected for other software.
1 Like
And now for the fun questions:
If table_id is the naming convention for PKs. What is the naming convention for FKs and how do you handle recursive table references?
J/K! Those questions are for heated SO threads 
In any case this seems to be solved as they will implement a configuration option so that each one of us can define the default pattern we want to use.
1 Like
The same as the PK for clarify, that way you now which “id” it is a key to
Wappler should be visual whenever possible, that’s its platform tag, so having to add alias should not be a requirement and I suggest this is the best DRY alternative.
Best of both worlds!
1 Like