August 26, 2010 at 11:37 am
CirquedeSQLeil (8/26/2010)
So here is my question of the dayHow do you convince somebody that archive data should not be changed?
Data integrity didn't work
Point in time visibility did not work
Reporting consistency did not work
Just had that conversation yesterday. If it is history it doesn't change. The way it is interpreted might change though.
Of course with DBCC TimeWarp...
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
August 26, 2010 at 11:38 am
CirquedeSQLeil (8/26/2010)
How do you convince somebody that archive data should not be changed?
<Headthunk><Headthunk>
August 26, 2010 at 11:41 am
Stefan Krzywicki (8/26/2010)
CirquedeSQLeil (8/26/2010)
So here is my question of the dayHow do you convince somebody that archive data should not be changed?
Data integrity didn't work
Point in time visibility did not work
Reporting consistency did not work
What is their argument for changing it? Was the data wrong in the first place? I'd say if they have a really good argument or are intractable, set up a snapshot for them while explaining the legal implications of using the changed data. That way they get to have their changed data, but don't actually change the archived data, they just have a separate set with their "corrections".
Mostly the argument is that it is the way it has been done for years now so why change it. Second seems to be lack of desire to change the code appropriately.
We receive monthly update files that should update current year data (and potentially data within the last year depending on month - jan may need to update dec or nov of prior yr) - which is acceptable. But once the year is closed out - that data should not be changed. The process to update the data permits the updating of data in prior yrs - which it shouldn't. I would like that code changed - and the resistance is that it seems unnecessary because everything works and it provides a "self-healing" mechanism. My rebuttal for self-healing is database backup and restore.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 26, 2010 at 11:42 am
Brandie Tarvin (8/26/2010)
CirquedeSQLeil (8/26/2010)
How do you convince somebody that archive data should not be changed?<Headthunk><Headthunk>
HAHA
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 26, 2010 at 11:45 am
Jack Corbett (8/26/2010)
CirquedeSQLeil (8/26/2010)
So here is my question of the dayHow do you convince somebody that archive data should not be changed?
Data integrity didn't work
Point in time visibility did not work
Reporting consistency did not work
Just had that conversation yesterday. If it is history it doesn't change. The way it is interpreted might change though.
Of course with DBCC TimeWarp...
The argument on what is history is: I just want to be able to change the data if I want to.
Next piece of the puzzle (a nightmare of mine)
IDs for the data may change on a monthly basis. :crying:
Should I stay or should I go now?
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 26, 2010 at 11:54 am
CirquedeSQLeil (8/26/2010)
Stefan Krzywicki (8/26/2010)
CirquedeSQLeil (8/26/2010)
So here is my question of the dayHow do you convince somebody that archive data should not be changed?
Data integrity didn't work
Point in time visibility did not work
Reporting consistency did not work
What is their argument for changing it? Was the data wrong in the first place? I'd say if they have a really good argument or are intractable, set up a snapshot for them while explaining the legal implications of using the changed data. That way they get to have their changed data, but don't actually change the archived data, they just have a separate set with their "corrections".
Mostly the argument is that it is the way it has been done for years now so why change it. Second seems to be lack of desire to change the code appropriately.
We receive monthly update files that should update current year data (and potentially data within the last year depending on month - jan may need to update dec or nov of prior yr) - which is acceptable. But once the year is closed out - that data should not be changed. The process to update the data permits the updating of data in prior yrs - which it shouldn't. I would like that code changed - and the resistance is that it seems unnecessary because everything works and it provides a "self-healing" mechanism. My rebuttal for self-healing is database backup and restore.
Ah, the old "inertia justification". Coupled with the "laziness justification" it can be hard to overcome indeed.
The threat of auditing is a good argument. Another might be to get a reference that'll show them what "closed out" means and let them know that if the data can be changed, it isn't "closed out" and accounting people will be vey upset if it happens.
The other tack I'd take is one that while valid, has an accompanying cliche that I hate. The "hit by a bus" argument. While the people there now know that things are fine the way they are, if they change jobs or are "hit by a bus", the people that come after them won't have the same understanding of the systems and the loopholes should be closed. Of course, this doesn't always work with the people being hit by the metaphorical busses, so you often have to bring this argument to others with authority who will worry about what new people might do.
On a side note, why busses? Why aren't people in these theoreticals brought up in too many meetings ever hit by taxis, trucks, private cars, trains, boats, airplanes, street vendor carts, horses, steamrollers or other construction equipment, trollies or subways?
Also, my finacee knows there are things in computers called "busses". She thinks I should carry some around with me so when people bring up the "hit by a bus", I can throw one at them. I think it is a great idea, but would take too much explanation after they're hit by one.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
August 26, 2010 at 11:59 am
CirquedeSQLeil (8/26/2010)
The argument on what is history is: I just want to be able to change the data if I want to.
At that point, I'd tell them flat out that that's not a valid argument and set up a meeting to bring in bosses. Or give them that snapshot.
Next piece of the puzzle (a nightmare of mine)
IDs for the data may change on a monthly basis. :crying:
Should I stay or should I go now?
They've seriously stated that IDs can change from month to month? What do they think they're doing? Why would IDs change? You may need to set up a "secret" ID column on your table that only you know of. You could set up a history table to keep track of the ID changes, but they'd just want to change the data in it.
--------------------------------------
When you encounter a problem, if the solution isn't readily evident go back to the start and check your assumptions.
--------------------------------------
It’s unpleasantly like being drunk.
What’s so unpleasant about being drunk?
You ask a glass of water. -- Douglas Adams
August 26, 2010 at 12:01 pm
Stefan Krzywicki (8/26/2010)
On a side note, why busses? Why aren't people in these theoreticals brought up in too many meetings ever hit by taxis, trucks, private cars, trains, boats, airplanes, street vendor carts, horses, steamrollers or other construction equipment, trollies or subways?
Also, my finacee knows there are things in computers called "busses". She thinks I should carry some around with me so when people bring up the "hit by a bus", I can throw one at them. I think it is a great idea, but would take too much explanation after they're hit by one.
I like the metaphorical spy. Though being hit by a steamroller could be pretty good.
I seriously like the computer bus to throw at people. But it would have to be a ton of them to make sure it would hurt :w00t:
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 26, 2010 at 12:02 pm
CirquedeSQLeil (8/26/2010)
The argument on what is history is: I just want to be able to change the data if I want to.
Ah, but they can change the data. But it has to be the CURRENT data, not the old data.
CirquedeSQLeil (8/26/2010)
Next piece of the puzzle (a nightmare of mine)IDs for the data may change on a monthly basis.
Ah, yes. One of our vendor supplied systems has that issue. The DBA at the time created fake keys and then truncates all related data each month end. Of course, the load does inception to date, year to day and month to date (three different tables), so truncating isn't a big deal.
On the other hand, I found out one of my new data load projects has a changing Record_ID on a month basis. After further research, though, I found a unique key to every record that never changes and no one realized was a natural key. DOH. So, look around a little, you might find something no one recognizes as a key.
Lastly, another data load I have doesn't even have a key or any referential integrity whatsoever. Gotta love government generated data.
CirquedeSQLeil (8/26/2010)
Should I stay or should I go now?
There's a song for that... Sit down with these guys, have a polite discussion, and see if you can get any concessions out of them. If not. If they are adamant about their positions and expect you to do the impossible... You should start looking, but don't burn the bridge in case you can't find anything else.
August 26, 2010 at 12:04 pm
Stefan Krzywicki (8/26/2010)
CirquedeSQLeil (8/26/2010)
The argument on what is history is: I just want to be able to change the data if I want to.
At that point, I'd tell them flat out that that's not a valid argument and set up a meeting to bring in bosses. Or give them that snapshot.
Next piece of the puzzle (a nightmare of mine)
IDs for the data may change on a monthly basis. :crying:
Should I stay or should I go now?
They've seriously stated that IDs can change from month to month? What do they think they're doing? Why would IDs change? You may need to set up a "secret" ID column on your table that only you know of. You could set up a history table to keep track of the ID changes, but they'd just want to change the data in it.
In all seriousness - my boss doesn't like this either. I have been chipping away and winning little by little. I thought I had won enough battles that I could tackle this monster - but may have to reconnoiter and try again.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 26, 2010 at 12:07 pm
Brandie Tarvin (8/26/2010)
CirquedeSQLeil (8/26/2010)
Should I stay or should I go now?There's a song for that...
Strictly for the song's sake. Gonna re-attack this problem in a week - from a different angle.:cool:
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 26, 2010 at 12:48 pm
CirquedeSQLeil (8/26/2010)
So here is my question of the dayHow do you convince somebody that archive data should not be changed?
Data integrity didn't work
Point in time visibility did not work
Reporting consistency did not work
Have him look up the definition of "archive" in a good dictionary. That might help.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
August 26, 2010 at 12:52 pm
Welcome back GSquared. I hope all is well with you.
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
August 26, 2010 at 1:00 pm
CirquedeSQLeil (8/26/2010)Should I stay or should I go now?
Yes. 😀
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
August 26, 2010 at 1:03 pm
WayneS (8/26/2010)
CirquedeSQLeil (8/26/2010)Should I stay or should I go now?
Yes. 😀
Reminds me of something I've said too many times: "Stay or go, but move away from the doorway!"
For best practices on asking questions, please read the following article: Forum Etiquette: How to post data/code on a forum to get the best help[/url]
Viewing 15 posts - 17,746 through 17,760 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply