There are three more "ideas" that I was sent that I want to discuss:
If your database needs constant data fixes (projectX, projectY), FIX THE CODE.
This is such a simple concept, but we seem to have missed it somewhere in our education. If you need to do the same data fix, but with different parameters, over and over again, there is a problem with your code. Rather than invest the energy in creating, executing and tracking data fixes, fix the code. At the very least, let the users fix the data themselves. Create a screen that accepts the required parameters and executes it on behalf of the user, with all of the proper auditing that needs to be in place.
If you are corrupting records, it isn’t the database, FIX THE CODE
It's amazing how many times the database has been identified as the culprit as to why the data is in it's current state. "Oh, something must have made SQL Server corrupt the data" or "Maybe SQL Server can't handle the load that we are asking it to do and it failed to do something we told it". Maybe the real answer is that SQL Server did exactly as it was told. Our code told it what to do and it did it. SQL Server is not an autonomous machine randomly changing data on a whim. If the data is corrupt, we, the humans in change, did it, not the machine.
If you have a 24 hour load process, don’t blame the DBA, the hardware, the OS, maybe FIX THE CODE
We've got really large machines in our UAT and Production environment. You would be amazed at what they are capable of doing, not in a day, not in an hour, but every minute!!!! There is enough processing power to do physics calculations on the interaction between dozens of objects in an environment ten, twenty or thirty times per second. There is enough processing power to correctly calculate and render a 3D environment in which these objects exist in real time and show them at thirty frames per second. What I'm trying to say is that the machines are more than capable of playing the worlds most complex and demanding computer games in existance and provide excellent response. The graphics and physics engines embedded in these games make thousands of calculations every second. Tens or even hundreds of thousands of calculations every minute. And yet, we're busy doing 100 records a minute into a database and we're happy.
Does someone other than me, and the person that highlighted these points, see a serious problem here?
No comments:
Post a Comment