Don’t Change Anything

Question

Don’t Change Anything

Steve Jones - SSC Editor

SSC Guru

Points: 736198
More actions
April 6, 2010 at 8:14 pm

#222922

Comments posted to this topic are about the item Don’t Change Anything

Viewing 15 posts - 1 through 15 (of 69 total)

You must be logged in to reply to this topic. Login to reply

Paul White SSC Guru Points: 150467 More actions · Answer 1

There seem to have been a rash of questions on the forums recently about how best to convert strings to dates in the database. Invariably, the thread features a number of comments along the lines of 'never store dates as anything other than one of the date/time types'.

Using the appropriate types and ensuring appropriate CHECK constraints exist, helps to ensure that the situation discussed in today's Editorial can (almost) never arise.

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

Rafael A. Colón Right there with Babe Points: 721 More actions · Answer 2

I am in completely agreement with this editorial. In our Company we have a separate Data Management team that deals with all the issues related to data, giving the DBAs the freedom to deal with our own responsibilities keeping the SQL servers secure, databases optimized and Backups up to date ,among others:-P

WayneS SSC Guru Points: 95460 More actions · Answer 3

Rafael A. Colon (4/6/2010)
... In our Company we have a separate Data Management team that deals with all the issues related to data...

Must be nice. Really nice. 🙂

Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes

If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!

Links:
For better assistance in answering your questions
Performance Problems
Common date/time routines
Understanding and Using APPLY Part 1 & Part 2

ben.mcintyre SSCommitted Points: 1878 More actions · Answer 4

While I agree with the sentiment of this article, I think the most important thing is: if you DO change any data, KEEP AN AUDIT TRAIL ! You MUST be able to undo ALL your changes later.

True, it's not good practice to 'fix' things off the cuff, but experience shows that sometimes on hindsight it's not good practice to fix things after exhaustive consultation and a mandate to do so, either.

It's often not until we get to the final stages of post-fix checking that we find why a fix was not so good, or worse, why a part of it was good but other parts very bad.

The point is that a very carefully maintained audit trail (with PK's, old values, new values) allows the checking process to be completed or undone as needed, elegantly and quickly, at any time in the future, until it's right.

Ben

Doron Hadar Mr or Mrs. 500 Points: 563 More actions · Answer 5

Excellent post, Steve.

One should never change data on the basis of assumptions.

craigsramblings Grasshopper Points: 12 More actions · Answer 6

The policy that I use is that the data in the tables belongs to the business not to the DBA. If it needs to be changed the business needs to approve what and how it gets changed. It's a very easy trap to fall into that just because you make sure the server is up and performs well that you (as the DBA) are responsible for everything on it. It's good to have clear boundaries - whether that be the hardware, the software, the SQL instance, the database or the data. Each layer needs to be owned by a specific business group, be that IT or Apps or ...

David Fulton-420388 SSC Veteran Points: 239 More actions · Answer 7

I'm in the camp that the DBA should maintain the data entered by the users. If data looks incorrect, then bring it to the users' attention and let them research it and make the appropriate changes.

To qualify the above, I'm in the Intellectual Property (IP) industry, so our databases manage patents, trademarks, and country law around the world. The domain knowledge involved is very specialized and a single patent or trademark can represent substantial revenue.

Best regards,

Dave

chrisfradenburg SSCrazy Eights Points: 9592 More actions · Answer 8

ben.mcintyre (4/7/2010)
While I agree with the sentiment of this article, I think the most important thing is: if you DO change any data, KEEP AN AUDIT TRAIL ! You MUST be able to undo ALL your changes later.

I don't think this can be emphasized enough. Any time one of our clients has us modify data in addition to requiring that they have a full backup handy I make a backup of the data being modified so if they realize that wasn't what they wanted to do or I made a mistake it makes rolling back easier. It also provides a history of what happened and I use a standard naming scheme to make it easy to trace the backup to what ticket it was requested in.

Paul White SSC Guru Points: 150467 More actions · Answer 9

David Fulton-420388 (4/7/2010)
I'm in the camp that the DBA should maintain the data entered by the users. If data looks incorrect, then bring it to the users' attention and let them research it and make the appropriate changes.

Is there a 'not' missing from that first paragraph...? :unsure:

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi

SLong SSC Veteran Points: 218 More actions · Answer 10

I agree that this situation is not in the DBA's hands to take it on themselves to fix bad data. In many industries, including the one I'm most familiar with, the financial industry, making one seemingly harmless data change can have grave consequences. In most cases, it wouldn't always fall back on the DBA for the infraction. The owner of the data would also be called to task by an auditor (possibly) over why they weren't aware of what the DBA was doing. It is great if the DBA is familiar enough with the data to point out "possible" issues, but it should definitely be left up to the data owner to research the issue and identify any downstream effects fixing it may have or if it really should be fixed at all.

Gill Rowley Ten Centuries Points: 1025 More actions · Answer 11

Good article Steve. Proper database design is very important, but I always tell my end users that I'm not in charge of the data. I'm only in charge of storing the data and keeping it safe. The data is only as good as what the end users enter.

It's not my job to change data I don't think is correct, but I do ask if the data is supposed to be what it is. If I get a answer to the contrary, then I'll go change it to what it is supposed to be.

chrisn-585491 SSCoach Points: 16006 More actions · Answer 12

In our Company we have a separate Data Management team that deals with all the issues related to data

In my company, 50% of my coworkers and 75% of my clients don't understand data types, databases or more than basic computer technology. So determining what needs to happen to data can be a rewarding experience.

:laugh:

george sibbald SSC Guru Points: 104210 More actions · Answer 13

David Fulton-420388 (4/7/2010)
I'm in the camp that the DBA should maintain the data entered by the users. If data looks incorrect, then bring it to the users' attention and let them research it and make the appropriate changes.

How?

sounds cart before horse to me. Should not proper constraints be set up in the database and or app to prevent bad data getting in there in the first place? a DBA cannot be held responsible for the data users try to insert, he can hardly sit there and watch data being entered.

---------------------------------------------------------------------

Paul White SSC Guru Points: 150467 More actions · Answer 14

george sibbald (4/7/2010)
David Fulton-420388 (4/7/2010)
I'm in the camp that the DBA should maintain the data entered by the users. If data looks incorrect, then bring it to the users' attention and let them research it and make the appropriate changes.
How?
sounds cart before horse to me. Should not proper constraints be set up in the database and or app to prevent bad data getting in there in the first place? a DBA cannot be held responsible for the data users try to insert, he can hardly sit there and watch data being entered.

Pretty sure the word 'not' was omitted from David's opener by mistake, George...:cool:

Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi