Database Design – How to Argue Against Duplicating Database Columns

Yes, it is quite unusual. This is mostly down to:

• People don't know it's possible- progressively people deal less with RDBMSs directly and know less and less features, preferring to do everything on the main (non-SQL) codebase. ORM users, for instance, comment their models
• Tools rarely show the comments easily, they tend to be buried and thus people don't see them
• Well-designed databases tend to be self-explanatory for someone who knows the "business". Proper table and column naming mean that most tables and columns might not need comments- redundant comments are bad; "this table contains students" as a comment on the "students" table is worse than useless. Constraints can also make some comments redundant (i.e. "this column must be null if that column equals 3" can be implemented using a CHECK constraint- and constraints can be easily listed).

I believe database documentation is useful; I like autogenerated documentation such as that generated by tools like SchemaSpy; these often make comments pretty visible. However, my experience is that documentation is mostly useful when learning the database- a few months in any project and you'll know the schema by heart, unless it is extremely complex, thus docs are not that useful for reference.

I would put the null checks in your mapping code, where you build your object from the result set. That puts the checking in one place, and won't allow your code to get halfway through processing a record before hitting an error. Depending on how your application flow works, you might want to perform the mapping of all the results as a pre-processing step instead of mapping and processing each record one at a time.

If you're using an ORM then you'll have to perform all your null checks before processing each record. I'd recommend a recordIsValid(recordData)-type method, that way you can (again) keep all the null-checking and other validation logic in one place. I definitely wouldn't intermingle the null checks with the rest of your processing logic.