An over-normalized table is expensive to fish in because of all of the joins. Examples of taking things too far could be having tables for everything that would otherwise be an enum in code and having to join into those tables in sproc reporting to get at what a numeric encoding is meant to represent. Either just have the numeric encoding in a database column and use an enum in code without a sister database table or jam the strings into said numeric column instead if you have to have reporting that is standalone in SQL that makes sense.
No comments:
Post a Comment