February 2, 2020 at 1:56 pm
...To many, many developers RDBMS are a temporary expediency which will soon be soon replaced by something "faster, easier, and better." The opinion of non-Sql devs about Sql (in general) is basically worthless...
Don't get me wrong, I'm not saying roll over and do whatever the developers want, they have to be willing to cooperate too, and respect that a DBA or Data Architect would have better knowledge about those kinds of things. It's funny, I remember when Object Oriented Databases were all the rage and developers thought since it was something more along the lines of how they thought it would replace relational databases, but it never really grew to more than a small niche environment. Over time, people came to realize that you could model any object database as a relational database, but only a portion of relational databases could be modelled as an object database, so the flexibility of the relational model prevailed. I've survived 26 years as an IT professional by being able to recognize and decipher solid processes and technology instead of jumping on bandwagons of the latest fad and niche solution.
February 3, 2020 at 9:05 am
Chris Harshman wrote:I don't think it's as much an attitude issue as it is a domain knowledge issue. I wouldn't try to tell .Net developers how to write C# code, but I've found no shortage of .Net people over the years who either are unable or unwilling to understand that there may be a better way than their way to do data storage and retrieval. Sometimes even if you explain the consequences of their decisions and design they are unwilling to change their mind. So even though developers may perceive that they are the good guys, my experience tells me it goes both ways.
To really get things accomplished in a productive environment, both sides need to be willing to discuss it and respect the domain of other parties involved.
Is it really a good strategy to cooperate? The other side opposes set based solutions as a matter of practical policy. To many, many developers RDBMS are a temporary expediency which will soon be soon replaced by something "faster, easier, and better." The opinion of non-Sql devs about Sql (in general) is basically worthless. Most of them tried to learn Sql and failed. So instead they obstruct, undermine, and further the prejudiced circumspection against sets. My fightback is a data access framework which is an "Anti Entity Framework." Instead of attempting to make data access an automated implementation detail of procedural server code it does the opposite. It makes the server code an automated implementation detail of the database code. That's my answer to the deluded rbar'ers.
I'm not sure I agree on this one - cooperation leads to learning. rather than fight them we can mentor them
MVDBA
February 3, 2020 at 10:42 am
I'm not sure I agree on this one - cooperation leads to learning. rather than fight them we can mentor them
^^^^^^^^^^^^^^^^
YES!!!!
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 3, 2020 at 2:00 pm
I absolutely agree that cooperation leads to learning. That's why I sit with the Developers and have a symbiosis with them. Cooperation does not mean letting bad stuff happen and the DBAs "surrendering" what they know will lead to immediate or future problems. That old adage of "knowing which battles to fight"? Yeah... I try not to fight battles... I try to educate folks so that there are a whole lot fewer battles but I'm not going to let something pass just because it's a "small battle". If it's wrong, it's wrong, period.
My biggest point here is that it's a fine line we walk and, unfortunately, it frequently seems that we're the only ones, on what is supposed to be a team, that are doing the "surrendering". That's not any more right than the problems DBAs surrender on.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 3, 2020 at 2:19 pm
I'm not sure I agree on this one - cooperation leads to learning. rather than fight them we can mentor them
Now I work in marketing... the only thing at risk is that we double book the underwear models
Cooperation is sometimes rewarding. At the right moment tho... hesitate. But only for a moment.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
February 3, 2020 at 2:34 pm
I think the trick is that we're all in the same boat, so stating why you oppose something but knowing that the final decision might be somewhere else is just the reality. It's figuring out how to keep the boat afloat despite whatever happens that is the goal. Playing the blame game just fractures whatever chance for a team there is. We all do it, but the goal is to do it as little as possible and relent once you've done it.
Except for Dan *clenches fist*…..screw that guy!
-------------------------------------------------------------------------------------------------------------------------------------
Please follow Best Practices For Posting On Forums to receive quicker and higher quality responses
February 3, 2020 at 2:59 pm
I agree... I hate the "blame game". That's why I get pissed off when people, who frequently don't know much about databases, blame the DBA for being a supposed bottle-neck even when the DBA is actually (usually) right about the impact something is going to have on the databases and all things that use it. We ARE all in the same boat and we all should be working towards the success of the company. When people finally realize that one person's perception of what "bottle-neck" is is actually someone being a good and proper "gate-keeper" and they finally make the same effort to cooperate for the sake of the company, then we'll be on to something.
I can actually say that because I've worked on teams where the DBAs were considered to be ugly trolls hiding under the bridge just waiting to prevent all passage and (like the current team I have the extreme pleasure of working on) teams where the DBA(s), the Developers, AND THE MANAGERS have a real live appreciation for what each other do and are hell bent on improving things for the company in all ways.
If it's worth doing, it's worth doing right.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 3, 2020 at 3:39 pm
I think the trick is that we're all in the same boat, so stating why you oppose something but knowing that the final decision might be somewhere else is just the reality. It's figuring out how to keep the boat afloat despite whatever happens that is the goal. Playing the blame game just fractures whatever chance for a team there is. We all do it, but the goal is to do it as little as possible and relent once you've done it.
Yes yes, and what Jeff said too. My experience has been the surrender direction has been one-sided going the other way. But I've been promoted up the chain to Senior Director because I treat the data as if it belongs to its appropriate users. Everyone is trying to contribute. "There's the right way, the wrong way, and the way things get done around here." The sooner you get on board with the last one the better for everyone involved.
Imo DBA's haven't had a good alternative to the newer methods of data access, like the Entity Framework, if we're being honest here. What "ease of data consumption" tools exist for DBA's to offer data services in a developer friendly way? In order to request data from a SQL stored procedure the client has to re-code the input and output parameters to be submitted. The response data must be translated again into a format the client can easily consume. In C# it's traditionally been done with 2 methods, 1 to run the procedure and 1 to call that method and handle the outcome. In EF it's only 1 method and serialization is handled automatically. This has been a big bottleneck for a long time.
Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können
February 3, 2020 at 4:07 pm
I absolutely agree that cooperation leads to learning. That's why I sit with the Developers and have a symbiosis with them. Cooperation does not mean letting bad stuff happen and the DBAs "surrendering" what they know will lead to immediate or future problems. That old adage of "knowing which battles to fight"? Yeah... I try not to fight battles... I try to educate folks so that there are a whole lot fewer battles but I'm not going to let something pass just because it's a "small battle". If it's wrong, it's wrong, period.
My biggest point here is that it's a fine line we walk and, unfortunately, it frequently seems that we're the only ones, on what is supposed to be a team, that are doing the "surrendering". That's not any more right than the problems DBAs surrender on.
ironically i picked a battle wisely today, a Project manager is raising a CAPEX (capital expenditure request) and i wanted £175,000 of new server .... when i showed them our azure costs for the month, it pays itself off in a year. new server YAAAYYYYY , but next "DBA needy moment" is going to be a while
plus - i have a new server to chew on, so management won't be expecting shouty emails soon
MVDBA
February 3, 2020 at 4:15 pm
I've worked on teams where the DBAs were considered to be ugly trolls hiding under the bridge just .
Hey - I might live in Mansfield, but we don't have bridges.. so that would just make me a big ugly homeless troll.. thanks dude 🙂
as for being the "gatekeeper" it's a bit like harry potter playing quidditch (sorry guys) we are the beaters - the guys who protect the "glory hunting snitch catcher" 🙂
MVDBA
Viewing 11 posts - 31 through 40 (of 40 total)
You must be logged in to reply to this topic. Login to reply