I must be missing something, but the "solution" with the 3NF and five separate tables with their own indices seems artificial and like pointless overengineering. Isn't this solved by a single index?<p>Or maybe a relational DB is already overengineering. Using a hash table (some libdbm lookalike) to map (ip,helo,from,to) to (time) solves the problem, too, and doesn't have a low performance failure mode.<p>This doesn't change the major point about everyone having been a newbie at point, though.
The important bit comes at the end:<p>> That's right, <i>I</i> was that clueless newbie who came up with a completely ridiculous abuse of a SQL database that was slow, bloated, and obviously wrong at a glance to anyone who had a clue.<p>> My point is: EVERYONE goes through this, particularly if operating in a vacuum with no mentorship, guidance, or reference points. Considering that we as an industry tend to chase off anyone who makes it to the age of 35, is it any surprise that we have a giant flock of people roaming around trying anything that'll work?
I'm kinda shocked that relational databases work so poorly out the box, that you can't even have a simple table with 4 or 5 values you care about, but have to split it out into 5 different tables and then create business rules about how to connect those into the original table.
I remember when I first started to do "real work" in mysql (instead of just tiny crud apps). i wanted to store a tree structure, and talked to the most skilled DBA in the room (who happened to be our group admin). Turns out, the way to do this in sql is to make parent pointers (not list of child pointers), exactly the opposite of how everybody else in the world does it. Later I learned that postgres has compound types and array types which work fine for trees.
I've been there too but wouldn't using an int to store the IP make more sense than pushing it out to its own table? Just as fast and one less table.
I think I care less about whether the programmer is clueless, and more about the immediate effects of that cluelessness. If their clueless implementation is meeting the minimum requirements and goals that it was intended for, then it doesn't matter if it's terrible or not, it's good enough. If it's not meeting the minimum requirements, then I want them to do it in a way that does.<p>Another thing I think about more often is when my code will die. Everybody's code gets replaced eventually. How difficult will it be for the next person to replace your code? What kind of impact are you having on future generations? If I write my code to be super efficient and "fancy", will it be that much more difficult to replace in the future? Could I have written it in a different way that made it easier to deal with? I hope I make the right decisions. I don't want somebody to be cursing me when I'm long gone.