June 12, 2014 at 11:10 pm
thomashohner (6/12/2014)
My first response is that I'm neither I'm a noob... But seriously I'm a report writer where do we fall? Red headed stepchild???
Heh... report writers. They're the disdain of many... and I don't know why. What the hell good is data if you can't turn it into information? That's what Report Writers do, from what I can see.
They also have it worse than a lot of other people. If you think the not so proverbial request to move a field one pixel is a PITA, feel the pain of the report writer. It's not a click'n'drag job as most would think. They have to know the data inside and out. They have to know how it's organized so that they can join all the pieces together to make some sense of it all. They have to be able to explain it all to all sorts of people including but not limited to a wide array of auditors whose sole purpose in life is to see if they can find something not quite right. Then there's the boss that want's the report yesterday, the thousand users that want it transferred to their spreadsheets and don't understand why you can't fit 2 million rows on a single sheet, the managers that don't understand that you can't have 5 years of dates on a bar chart that's only 6 inches wide and still be able read each date nor why having a gridline for each date turns the background to solid black or blue, or that a pie chart with a 100 segments really isn't going to do anyone any good or why the blue segments turned green when printed on yellow paper and the yellow segments seemed to disappear, or why you can't print red on a black'n'white printer, or try to explain why it's not a good idea to print a million row report, etc, etc, etc.
Then there's the boss that want's you to fudge numbers "just this one time".
My hat's off to Report Writers and people in BI. They have to support "Business Intelligence", which is frequently an oxymoron. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
June 13, 2014 at 12:05 am
Sorry... dupe removed.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 13, 2014 at 12:08 am
Sorry... another dupe removed.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 13, 2014 at 6:14 am
Jeff you must have a crystal ball??! You just described yesterday for me. I actually had to say this in a email to one of our administrator's, "My reports only show what is, not what you wish your staff had been entering for the last 6 month's".
***SQL born on date Spring 2013:-)
June 13, 2014 at 6:36 am
Tell them it is a report. If they want a work of fiction they should call Stephen King.
Cheers
June 13, 2014 at 6:52 am
thomashohner (6/13/2014)
Jeff you must have a crystal ball??! You just described yesterday for me. I actually had to say this in a email to one of our administrator's, "My reports only show what is, not what you wish your staff had been entering for the last 6 month's".
I'm in a very similar situation to you Thomas and have been doing it for the same length of time. [rant] I'm constantly explaining to managers that the way to solve the problem is to ensure that their data entry staff do their jobs properly. I can't find what isn't there but it's easier for the manager to come and ask me to account for things not being entered correctly than it is to tell their staff to adhere to standards and protocols that have been in place for years. [/rant]
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
June 13, 2014 at 7:19 am
jfogel (6/13/2014)
Tell them it is a report. If they want a work of fiction they should call Stephen King.
I am so using this line:laugh:
@BWFC
I actually had this conversation a few weeks ago. A little background. We had a department that was using some unknown method of data collection for the last 7 years it was then inputted into excel sheets. I standardized it, created a method for data capture from clients, showed them how to enter via the application. 3 months go by and they want to see how this new method is working.
Me: Here's your first report on the new method, please look it over.
Them: hmm, nice it looks pretty and clean.
Me: Thanks
Them: But there is one major problem
Me: What's that?
Them: These numbers don't match our baseline numbers for the last 7 years. They look much better for us. I think this may raise a red flag with our funders.
Me:??? Well, I'm confused how were you getting your numbers before.
Them: Well we would ask the manager how many people came in, she gave us a educated guess on what she thought she saw for the day. We then put that into a spread sheet and applied a formula.
Me: Formula? What does the formula do?
Them: We aren't really sure? But it gives us our numbers we use.
Me: So you are confused why hard data entry and retrieval with methods of integrity is not matching 7 years of guessing with a mystery excel sheet formula.
ME: Hmmmm, not sure I will be able to answer this one.:hehe:
Them: yeah, I know it doesn't make sense does it.
***SQL born on date Spring 2013:-)
June 13, 2014 at 7:37 am
It's hugely frustrating when your results are questioned because they don't match what is expected or what somebody wants to see. I've recently been sending a lot of emails to the effect of 'your previous data was wrong because...' The other one we see a lot is 'this person wasn't on Report X, why not?' The usual answer is 'they're not supposed to be and you could have found that out yourself'.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
June 13, 2014 at 8:11 am
thomashohner (6/12/2014)
My first response is that I'm neither I'm a noob... But seriously I'm a report writer where do we fall? Red headed stepchild???
IMO you're a client consuming the data. Therefore it needs to be set up in a way that you can access it for your tools.
This may mean datamarts, cubes, denormalized tables, views, or anything else that meets YOUR business requirement. A separate database for reporting makes it much less painful in some respects because you're not accessing the clean happy data. 🙂
You should also feel comfortable going to a database developer and/or DBA for help with performance tuning queries if you're not sure you're doing it in the most efficient manner.
June 13, 2014 at 4:38 pm
John Fager (6/12/2014)
I'd say that when there is a book almost the size of the Bible describing just "Inside the SQL Query Optimization Engine"... um that's where we are in trouble already! It's CRUD for data.
I believe you've just illustrated my point, as well. 🙂 The engine is as complex a piece of machinery as the front end app. It's not just CRUD for data, though I understand the perspective. In the end, an app is just 'an interface for the data to tell us when it's requested and to sort and format the results' to the database.
SQL is ridiculously complex and the underlying architecture and language has simply not be rethought or advanced in ways that other languages and technologies have. The roots are deep, complex and old.
There are reasons for that. Note, this isn't a dig at the app devs, they can do this model because they don't need persistence. But for every 10 changes the app makes (and can be modularly rolled back out with code controls for the module), we make 1, and we make it slowly. Lost data can't be easily recovered. Worse is corrupted data being detected. I don't mean corruption caused by disk failures, I mean logic failures or unanticipated intersections of code.
Those roots are deep and old to keep things from moving around too much on purpose. I'm not saying we're against adopting new techniques and technologies, or methods of doing things. I'm saying the base libraries are never going to move much at once because of the caution that's built into our very atoms by the time we become a senior at a location.
A little clarity on this... It works great; not just on paper either. We don't avoid optimizing for a specific engine at all. Via architecture, we ensure that SQL optimization code stays in it's appropriate repository and is accessed in a very specific way and place.
AH! My apologies then, when I hear of this type of architecture I usually get the agnostic code discussion, so I jumped to an assumption there, apologies.
Caching, specific connections and query guts are out of their reach and safely in the hands of experienced app developers that can work very well with SQL and the DBA. When it's time to modify data stores, there is nowhere to look except in the repositories to make the switch. The new DLL's simply need to be added and the configuration changed. None of the business logic, web code, UI stuff and app code has to be changed or republished at all.
We started looking at this to be more fault tolerant as the cloud evolves and apps are mobile and sometimes temporarly disconnected on devices but still should work to a certain extent. As it turns out, good architecture also keeps app developers that don't understand SQL very well from writing code that generates queries that will never work under load.
You have a more advanced architecture than most I've heard of. I'm not sure, from my perspective, that I'd understand it thoroughly but you've definately thought it through and everything sounds like a solid approach from my limited knowledge. It seems like a lot of hoops to jump through but if you're not seeing a lot of pain in transferring between that many layers, and it's significantly helping your maintenance, awesome!
I'd love to see a white paper on that one. If I can make enough sense of it I'll hand it directly to every ORM default settings touting maniac I can find and help them build it. :w00t:
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA
June 23, 2014 at 5:05 am
simon.crick (6/12/2014)
Tension arise when Developer and DBA roles/responsibilities are not properly separated.It sounds simple because it is. Problems only arise when people forget the basic principles of software engineering, i.e. every component must have a well-defined interface, and users of a component must not bypass the interface or make any assumptions about how the component works internally.
You would think so. But when I've suggested this in interviews for some places in the past, it's been received slightly less well than if I'd something obscenely biological
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
June 23, 2014 at 5:35 am
Gary Varga (6/12/2014)
My point is that, bearing in mind the editorial, the whole way of thinking is as flawed as the value of the number of legs as described in Animal Farm (the George Orwell book for those who are aware of other less literary references that can be attributed to). And no I am not calling DBAs pigs 😉
Personally I see myself more as Boxer
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
June 23, 2014 at 6:32 am
andrew gothard (6/23/2014)
Gary Varga (6/12/2014)
My point is that, bearing in mind the editorial, the whole way of thinking is as flawed as the value of the number of legs as described in Animal Farm (the George Orwell book for those who are aware of other less literary references that can be attributed to). And no I am not calling DBAs pigs 😉Personally I see myself more as Boxer
Generalising, most DBAs are. They do a lot of the heavy lifting and have zero interest in the politics.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 25, 2014 at 4:47 am
thomashohner (6/13/2014)
Jeff you must have a crystal ball??! You just described yesterday for me. I actually had to say this in a email to one of our administrator's, "My reports only show what is, not what you wish your staff had been entering for the last 6 month's".
I have a metaphorical wardrobe rammed with those t-shirts.
Do you get
<Whiny voice> "Well, the computer should just know"
"Well ... you must be able to get it from somewhere"
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
June 25, 2014 at 7:32 am
andrew gothard (6/25/2014)
thomashohner (6/13/2014)
Jeff you must have a crystal ball??! You just described yesterday for me. I actually had to say this in a email to one of our administrator's, "My reports only show what is, not what you wish your staff had been entering for the last 6 month's".I have a metaphorical wardrobe rammed with those t-shirts.
Do you get
<Whiny voice> "Well, the computer should just know"
"Well ... you must be able to get it from somewhere"
Good Lord, I hear those two quotes verbatim almost weekly. I always try to explain that computers/software are just tools. They do not do your work for you. However it always falls on deaf ears :crazy:
***SQL born on date Spring 2013:-)
Viewing 15 posts - 61 through 75 (of 79 total)
You must be logged in to reply to this topic. Login to reply