In the last hour, I’ve been told
- Don’t use SYSDATE in inserts/updates because although it’s bog standard SQL (I’m not sure if it’s ANSI standard, but it’s pretty common), it’s not supported by all Microsoft databases (even though we only use Oracle in this project)
- Do use VARCHAR2 instead of VARCHAR, because although VARCHAR2 is only supported by Oracle, and in the current release it’s just a synonym for VARCHAR, some day it’s going to have different comparison semantics than VARCHAR and Oracle says to use it, so we have to use it.
I’ve also been told that these two tables, which I have to populate by hand using manually taking the rows and columns of a spreadsheet and writing “INSERT…VALUES(‘row’,’column’,’value’)” statements several hundred times, can’t use semantic primary keys because they want to use UUIDs. So instead of looking at the spreadsheet and seeing that in the row labelled “Insurance” and the column labelled “Security” that the value is “V” and converting that to “INSERT … VALUES(‘insurance’,’security’,’V’)”, I’ve got too look up the uuid for the Insurance row and the uuid for the Security column, and change that to “INSERT … VALUES(‘6BAC51EC-C636-4C31-9E95-367062AC23F7′,’C78BF79B-3178-4F07-ACD3-92DF2742C932′,’V’)”. And I’ve got to do that several hundred times. Yes, that seems *much* less error prone that using keys I can actually tell what they mean and easily tell if I’ve got the wrong one. Oh, and even better, the code that uses the information in this table will have to hit the database to look up these uuids so that they can find the value of the “insurance” versus “security” instead of just coding those values directly.