T-SQL Tuesday #83: Why Leave Well Enough Alone?
In the 15 yearsI have been using databases professionally, we’re still dealing with:Peoples’ names are split into first name, last name and middle initial fields. Ignoring that this falls afoul of several of the myths programmers believe about names , the first name column was defined as CHAR(10) in a standard installation. How many characters are in the name Christopher (hint:I had to take off a shoe to count them all)? Other arbitrarily short column sizes which cause problems as the system scales out in usage. For example, an event ID field that’s 8 characters:2 letters and a 6-digit number which is used as a sequence. Guess what happens when you hit the millionth event in that sequence. Processes originally developed as transactions (for good reasons), but not designed in such a way that they scale to today’s demands. NOLOCK hintseverywhere. It’s even in newly-developed codefor this application. Cursors used anytime a set of records has to be updated with a small bit of conditional logic built in. Aset-based operation with appropriate CASE statements would work much better.
The primary system I deal with on a daily basis was originally developed as a DOS application and several of the above examples are drawn from it. Looking at the core tables and columns, it’s easy to identify those that began life in those early days they all have 8-character names.Time moved on and the system grew and evolved. DOS to windows. Windows to the web. But the database, and the practices and patterns used in the database, haven’t come along for the ride.
Data schema conversions can be hard and disruptive you need to update your application, your stored procedures, and provide customers/users with a clean migration path. Code changes require testing. Complexity and cost grows every time you introduce changes. I get that.
But by not keeping up with the advancements of the platform your data resides on and ignoring the evolution of how to work with your data, you do your customers, users, partners, colleagues and yourself a disservice.
How do you improve this? I’m certainly not advocating for scrapping everything and rewriting all of your code. Complete rewrites are generally a bad idea .
What I am saying, however, is:You need to be constantlywatching the state of the platforms your software runs on. If you drop support for a particular version (say, dropping SQL Server 2005 support as Microsoft no longer supports it), start evaluating the 2008+ features that are now open to you. Drop support for old versions of SQL Server. Don’t let the past shackle your future. Get outside opinions from trusted sources. Whether it be from your localuser group, a short consulting engagement, or bringing in new people. But most importantly, when you seekadvice,make use of it. Don’t ask for advice and then ignore it. Don’t accept the status quo. Anytime you’re working in a piece of code, review the whole thing. Can this section be cleaned up? Is it even needed anymore? Has the system scaled in usage/data volume that it needs to be re-thought entirely? Have you learned something new from your favorite SQL Server blog or a SQL Saturday event that you can apply to it?
That last point iswhere everyone responsible for an application or databasecan make the most impact. To co-opt Baden-Powell’s last message to the Boy Scouts of the world : Leave the code a little better than you found it . If you do this every time you touch a component of your database, you’ll make enough incremental updates that these 15 year old problems willgo away and stay away.
本文数据库（mssql）相关术语:熊片数据库 mssql数据库 oracle数据库 pubmed数据库 access数据库 万方数据库
本文标题：T-SQL Tuesday #83: Why Leave Well Enough Alone?