October 9, 2011 at 9:47 pm
Comments posted to this topic are about the item A Nice Refund
October 10, 2011 at 12:17 am
"While application developers will likely write most of the code, including lots of the CLR functions, procedures, and other constructs, who do you think will be responsible for the system? That's right, the DBA. You'll be the first and last line of defense and the one that will likely shoulder a lot of the blame for issues. Fair or not, I expect that DBAs will become more likely the scapegoats for issues."
That's a situation I have never seen. In the cases where I've seen things go wrong and bad, it's never been the dba that's been held accountable. First of all the focus usually goes to the team that works or built the application if it's an in-house project and then there might be an investigation depending on the error.
It seams highly illogical to go to the dba no matter what happened and blame him, or am I misinterpreting you? Going to the dba and ask for help to investigate as one of the first things to happen is of course happening.
October 10, 2011 at 2:03 am
The reality that seems to exist at my work is that the DBA is often directly responsible for only a small subset of activity. Often the issue we have is who to pass on issues to - the network team, the server team, the developers, etc? Sometimes this is a cause of frustration and I for one often wish I was directly in control of more of the variables...
October 10, 2011 at 2:50 am
I'm with IceDread, I don't see this. Our Client Services Manager who is the interface between project team and client will find out what went wrong. In general we do not maintain a blame culture as we all understand anyone can make an error. Of course for a gross negligience as quoted that would likely not be the case - fingers crossed I never get one that goes that far.
October 10, 2011 at 3:24 am
It's really funny how DBA's and Developers always at each others throats about who is right and who is wrong. Quite sad instead of both professionals just sucking up their pride and trying to help each other.
October 10, 2011 at 8:04 am
I consider CLR functions to be one of the least useful features introduced in SQL Server 2005. Although I can see a niche use for it when a developer needs something like a custom statistical function, I don't see a trend where most databases at large will eventually leverage them. Even for a back office process with no GUI, the business logic should be implemented in an SSIS package, BizTalk, or a custom written .NET service application. The database should be a container for data, and the DBA's job is to insure that the data is accessible, consistent, and secure.
Also, I think that a corporation would be reluctant to use the DBA as a scapegoat. As a rank and file salaried employee (as opposed to an executive with stock options and a golden parachute) there is nothing to stop the DBA from blowing the whistle and causing a big public stink.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 10, 2011 at 12:15 pm
I'm fortunate that in my environment the DBAs do development and we have strict rules here about keeping business rules and appropriate data processing in the database. Most of the general application developers feel fine concentrating on the visual side of Web and stand alone applications. They frequently come to the DBA and say "Gosh, I'm processing this stored procedure result set and my array handling is way too slow; can you write an aggregate stored proc for me?". They have seen for a long time the benefits of keeping data handling in the database. We also only let trained or supervised people write SQL. General application programmers don't have the skill set necessary.
October 10, 2011 at 2:23 pm
Everything starts with the DBA. I am constantly hearing 'We are having a problem. Users are complaining about....'. Can you look for problems with the database?
It always starts with the database....the DBA must know their system well enough to be able to find the issue or be able to prove that it isn't with the database. Especially given that most times the users don't say what the problem really is...I've spent time looking for issues only to have a user say...oh yeah, and what I told you the error was isn't so...here's the actual error message.
Developers rarely want to start with checking their code or application. Start with the database and work the way back - even though 9 times outta 10 in the past it has been on the application side.
Oh well, it is all part of the job of being a DBA.
-SQLBill
October 11, 2011 at 2:50 am
@EricGray
I am a general application programmer (admittedly of some experience) and I certainly believe I have the skills to write SQL. Even unsupervised, and without a lot of training. I have always worked in small companies and have never been in a position to call on DBAs for any proc writing, let alone a simple bit of aggregation. For instance I have just written a PIVOT, performant across millions of rows which will evaluate for several different timeframes (quarters, months, years) with running totals, percentage changes, at different detail levels.
Is this friction between parties a big company thing? I think at my shop(s) we all understand we need to concentrate on providing solutions to the customer (or go bust and no longer have gainful employment!). I will invariably comb my code extremely carefully prior to suggesting anyone else has got it wrong.
October 11, 2011 at 7:53 am
I suspect that most of the responses have been coming from Production/Core DBAs and not from Development DBAs.
Our Production DBA is constantly espousing the view that "DBAs DON'T own code"; however, as a Development DBA I do own code. Therefore, whenever something untoward happens, developers, the business, and(all to frequently) the Production DBA and my boss jump down my throat and blame me. Also, I seldom if ever get an apology when I establish beyond a shadow of a doubt that it wasn't my code that caused the problem. So, I am already experiencing the issues you are forcasting.
Another issue involved in the DBA getting the blame is that the DBA Team is the last line of defense against poorly written queries that result in poor performance as well as problems with applications doing things that are unreasonable and damaging. Unfortunately, I have also found that shops where developers write their own SQL statements, stored procs, etc., and design their own tables are also shops where recommendations of the DBA Team are viewed as being somehow suspect. :crazy:
Ralph D. Wilson II
Development DBA
"Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the ax."
A. Lincoln
October 11, 2011 at 12:09 pm
@Old Hand
The operative phrase here is simple. Since we've discovered how much faster it is to do data manipulation on the database server rather than send millions of rows in a data set back to the application server for processing we get very complicated in our SQL. Statements that run a hundred lines+ or dozens of statement operations tied together through temporary tables not being uncommon. Just like any critical programming this takes a lot of experience; you go to be doing this everyday and you need to understand how to analyse complicated execution plans. Its not a question of who is at fault for poor performance, we know its the development DBA since that is where the heavy lifting occurs. Bugs in the application interface? We go after the Java guy.
October 11, 2011 at 12:17 pm
Eric Gray (10/11/2011)
@Old HandThe operative phrase here is simple. Since we've discovered how much faster it is to do data manipulation on the database server rather than send millions of rows in a data set back to the application server for processing we get very complicated in our SQL. Statements that run a hundred lines+ or dozens of statement operations tied together through temporary tables not being uncommon. Just like any critical programming this takes a lot of experience; you go to be doing this everyday and you need to understand how to analyse complicated execution plans. Its not a question of who is at fault for poor performance, we know its the development DBA since that is where the heavy lifting occurs. Bugs in the application interface? We go after the Java guy.
Unless, of course, the Development DBA is, in effect, lied to about how to determine the nature of the "heavy lifting" that is to be done. If there are a set of reules defined as to what and how data is to be manipulated and then the data is manipulated in accordance with those rules, is it the fault of the Development DBA if someone decides or realizes that the rules are in error? Or if the controls that drive the process but that are embedded in the database are set up wrong or not set up at all?
Just as with any developmental process, the process will execute, by definition, correctly as designed. The question becomes whether the design is, in fact, correct and/or whether the design has been correctly implemented. However, that is seldom considered because it is far easier to blame the "problem" on the database, the DBA, or the Development DBA when it may be an application developer, a Business System Analyst, a User, or a Manager who have, in some way, incorrectly stated the Rules/Requirements and then lays the fault of the missing information at the feet of the DBAs.
Ralph D. Wilson II
Development DBA
"Give me 6 hours to chop down a tree and I will spend the first 4 sharpening the ax."
A. Lincoln
October 11, 2011 at 12:38 pm
Several years back, I was working on a government contract to develop the database backend for a web application that would query a large accounting datamart, and then build a datagrid for baseline budgeting. The end users could drill down on hundreds of hirearchal line items and edit spending estimates.
The complaint coming back from QA was: "Every time we change a cell or drill down on the datagrid, it takes the database two minites to refresh the data. It's just a thin-client web application, so it must be the database spinning it's wheels."
So, I setup a SQL Profiler and ASP.NET Page stack trace. Just as I knew, SQL Server was completing the call and returning data in 2 seconds. The problem was that the 3rd party datagrid control was pulling down about 3 MB worth of javascript every time the datagrid was changed, and it took the web browser about 2 minutes to render it all.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 11, 2011 at 3:19 pm
call.copse (10/11/2011)
@EricGrayI am a general application programmer (admittedly of some experience) and I certainly believe I have the skills to write SQL. Even unsupervised, and without a lot of training. I have always worked in small companies and have never been in a position to call on DBAs for any proc writing, let alone a simple bit of aggregation. For instance I have just written a PIVOT, performant across millions of rows which will evaluate for several different timeframes (quarters, months, years) with running totals, percentage changes, at different detail levels.
Is this friction between parties a big company thing? I think at my shop(s) we all understand we need to concentrate on providing solutions to the customer (or go bust and no longer have gainful employment!). I will invariably comb my code extremely carefully prior to suggesting anyone else has got it wrong.
It has been my experience that the larger the organization, the more divided the groups become. That's why I prefer working in small shops where the people have to cooperate and to get things done. You also have a lot of cross-training and personal development and enrichment.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply