Nah, it’s not because of you. It’s true for any programmer that if you don’t explore/use a particular feature regularly, you might remember that it should be possible, or even a rough outline of how to do it. But you don’t necessarily remember exactly how to do it right off the bat. It’s normal to have to whip out a SQL query tool or IDE and test/explore a problem to see what works or doesn’t work.
I understand why you want to keep the LotNo size/complexity to a minimum for human entry, makes perfect sense.
I lean this direction on projects where I have control over the code which will touch the database. Examples would be a project where multiple applications connect directly but I’m writing them all, or writing the data abstraction layer for them all. Another would be a project where multiple applications (web, desktop, mobile, whatever) need to talk to the database but do so indirectly through an API.
Triggers are for making sure Y happens in response to X no matter what app is connected to the database. But if you can centralize the behavior in a layer above the database it’s often easier to write/maintain.
I would say that it’s best practice to put logic which preserves database integrity into the database when there’s a chance that a client will not contain or respect said logic.