A coworker asked me this morning about database design best practices–specifically, is it better to A) ensure important primary key values are consistent across environments (dev, test, prod) and store those values in constants, or B) to ensure that those rows are sufficiently unique so that the application can query the primary key values as necessary. My immediate reaction was that option A was a bad idea, because I don’t like hard-coding values, but as we talked, I agreed that it would be more performant than option B, since it avoids extra queries. I ended up suggesting a third option–make the values sufficiently unique, as in option B, but have a post-deployment process that queries the primary key values and stores them for faster retrieval when necessary.
However, this discussion got me thinking about the nature of best practices, and how frequently there are additional considerations beyond the simple “always do this” that many people apply to them. The more familiar you are with a system or process, the more likely you are to find situations where the best option–note, of course, that what constitutes best varies–involves a “violation” of the best practice.
In this case, the best practice is to never hard-code values. But if it’s a value that’s being referenced ten thousand times a day, then it’s very possible that hard-coding will have a significant, noticeable performance benefit.
Similarly, Appian best practices (these days) are to use synched records instead of custom data types (CDTs). There are many benefits for this, which I won’t go into since I don’t intend this article to be a commercial for the company I work for. But I was talking with a coworker a few weeks ago about a problem he was trying to work around; the answer was to use a CDT, but he was jumping through many extra hoops to avoid that, since “CDTs aren’t best practice any more” (paraphrasing).
Of course, this is something we run into in many aspects of our lives. In Scouting, we teach the proper procedure for handing a bladed weapon to someone else–eye contact, handle first, don’t let go until there’s a verbal confirmation, etc. But if I’m working in a tight space and I hold my hand out for a tool, I may not be able to make eye contact. Similarly, driver’s ed classes emphasize following the speed limit–but there are roads where traffic regularly goes notably faster, and actually holding yourself to the limit can make you into a hazard. And parents teach their children many things that are true–up until they’re not. Examples will, of course, vary by household; in ours, for instance, best practice for doing the dishes includes that the person who cooked isn’t responsible for cleanup–but that can change for a variety of reasons.
So, best practices are there to teach us how something should be done, the vast majority of the time. However, it’s important to recognize that the more familiar you are with a system, they more you’re going to know when it’s appropriate to do something else. The tricky part, really, is understanding when you’ve hit that point–where you know for certain that the best option is to go against the best practices. My rule of thumb for this–my best practice, if you will–is that if you have any doubt, you’re not there yet.