Monster Maker wrote:
People say simplicity is familiar.
Not the people I'm around (including me) Also when I learned the acronym, KISS was a bit more insulting than just calling me silly. I don't have a goal to make things simple, my goals are to make it easy to understand, meet the requirement and my changes don't break anything. A lot of times my goal is to make something more performant. All of that sometimes also leads to making the query simpler to understand as well. Sometimes Simple just ain't possible. I had this bug on a stored procedure, traced the performance problem to a view, since I didn't have a bug on the view and the logic was gawd-awful, created my own logic in the sproc that transformed the performance from minutes to seconds. My results exactly matched the original result without using the view. Suddenly the performance of old and new sproc matched, but I was getting more results than the original sproc was now getting. Traced the unchanged sproc back to the now changed view. Someone had used a similar technique I used but their where clause didn't include all the extra data the other included. So did he fix the view to meet new requirements, or screw it up when going to the new process and not matching up the original selection which I had done? I certainly didn't know the real business requirements to say which (or neither) was doing things correctly.
