June 12, 2014 at 10:08 am
Hollywood should make a film called "A Day Without a DBA" just to show the ignorant public (and cocky app developers) what a total global disaster it would be if we ever decided to step out for lunch and never came back. 😉
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
June 12, 2014 at 10:12 am
Eric M Russell (6/12/2014)
Hollywood should make a film called "A Day Without a DBA" just to show the ignorant public (and cocky app developers) what a total global disaster it would be if we ever decided to step out for lunch and never came back. 😉
Seen worse plots on the big screen!
😎
June 12, 2014 at 10:17 am
The problem does lie with the different personalities needed for the different roles.
The DBA does indeed need to cherish stability. (S)he will naturally be averse to change unless it is very carefully staged because when the whole system crashes and burns, it will be the DBA who gets the blame. Being a DBA is a bit like being a husband (sexism alert!). Like a husband, the DBA can only fail. Success is regarded as normal and not to be praised. Many of the DBA's I have worked with (and its a large number) exhibit signs of Asperger's, so much so that if I were interviewing someone for a DBA job I would consider Asperger's syndrome to be a positive attribute.
The Developer's job is to create and push the limits. Although I am a bit of a cross-breed in this respect (33% DBA, 67% Developer), when I'm writing code, it feels like writing a novel. One develops the plot and handles the twists and turns as the characters fail to do what you want them to do, or do something you don't want them to do.
ETL processes show up the differences rather well. A typical DBA tends towards using SSIS, whereas a typical developer will tend towards Stored Procs. I use both, but I find that's not a common approach amongst my colleagues.
In a happy company Developers and DBA's can very happily co-exist (various UK National Health Service implementations show this happy trait). In other companies demonstrate the futility of the sentiment "the cowboys and the farmers should be friends" - Oh dear, i think I've just revealed my age!
June 12, 2014 at 10:18 am
Throwing in an other 2c, it is much worse when duties and responsibilities fall between the different groups than occasional clashes or issues. And it definitely isn't about who's [put what ever you want here] is bigger than the other, that kind of attitude for me is a show stopper!
😎
June 12, 2014 at 11:05 am
glyn-1145829 (6/12/2014)
Success is regarded as normal and not to be praised.
Spot on. Also, unemployment for a DBA is only one stupid mistake away.
glyn-1145829 (6/12/2014)
Many of the DBA's I have worked with (and its a large number) exhibit signs of Asperger's, so much so that if I were interviewing someone for a DBA job I would consider Asperger's syndrome to be a positive attribute.
People have said I'm strange, but never this.
glyn-1145829 (6/12/2014)
The Developer's job is to create and push the limits.
Gotta disagree on pushing the limits. In something that may be true; however, sometimes that would just make them rouge.
glyn-1145829 (6/12/2014)
ETL processes show up the differences rather well. A typical DBA tends towards using SSIS, whereas a typical developer will tend towards Stored Procs. I use both, but I find that's not a common approach amongst my colleagues.
Same here, but I tend to see this backwards. I've seen more devs setup a multiple step DTS/SSIS job or even an Agent job to do something that could have easily been done in a procedure. When I find those I convert them to procedures whenever possible.
Cheers
June 12, 2014 at 11:35 am
At the end of the day it is what the business and the customer need. If the culture of the company promotes that, then a developer's enhancement which degrades response time can be negotiated in terms of the greater business need. Can the business live with this risk for this benefit? But that requires leadership, generally from management outside of either team.
Even the tone of the article brings to mind two kids in a classroom fighting because the teacher (read management) is AWOL.
Humility goes a long way too! When encountering someone of a different specialty, think about how much you can learn from them, rather than how they are going to get in your way, or how much smarter you think you are than them. I have encountered so many people deemed "difficult" that really weren't. But I also try to respect that they probably know a crapload more about what they are doing than I do. Conversely, I can educate them about my needs and what I do for the business.
But alas, it does take two to dance. When one doesn't want to dance, then management surely needs to step in. Oh management . . . management . . . that's weird they were just here . . .
June 12, 2014 at 11:45 am
One of the greatest DBA's (he also handled the servers and SharePoint) I had the pleasure to work with was quite a long way past Aspergers down the route to serious Autism. He embraced his condition and recognised that attention to detail, desire for stability and a certain inability to understand people's emotional responses were positive attributes in someone on whom the whole company depended for the stability of their systems.
The people he works with don't really understand him, and they get upset when he won't make changes to their SharePoint system unless the requests are put in writing (paper) and slipped under the door of his office. He comes to this office every day and locks himself in except for lunch and bio breaks. In the end the owners of the company found that they also had to communicate via change requests on paper, slid under the door. He rejects many change requests for perfectly sound technical reasons.
Why don't they fire him? Because they NEVER EVER have any problems with their servers or with their SharePoint implementation. Result - Happy employee with a sense of achievement and happy company with a (rather rare) rock solid SharePoint, SQL Server implementation.
Fortunately the company works in the Healthcare industry and so they accepted the irritating attributes of this guy along with the huge benefits he brings.
So when I say Aspergers can be a benefit for the DBA role, I'm not being flippant. If someone with Autism can do so very well in the demanding DBA role, it's not surprising that people with Aspergers can do similarly well.
June 12, 2014 at 12:19 pm
I think Aspergers is on its way out as a diagnosis. Regardless, We've all worked with people who are difficult and the difficult ones who stick around (read not fired) do so because their results far outweigh the difficulties in dealing with them. This is true for someone with Autism, people who are just plain strange and even people who are straight up jerks.
Cheers
June 12, 2014 at 1:30 pm
The DBAs keep my database servers running and happy. In return I keep them informed of things that may impact (or may not) the database servers.
Going to have a long running query? Contact the on-call DBA to make sure it's not going to cause problems.
Adding a bunch of data? Contact the DBA team to confirm the space is available.
Security? Oh yeah. Create me some accounts with EXACTLY the minimum access my application needs.
We both do our parts and we work together. The trick is to get the DBA involved at the beginning once I have an idea of the requirements so there's no surprises down the road and all the paperwork is done in plenty of time.
We're not in competition here. There may be some friction when someone gets demanding or inflexible but otherwise it should be a cooperative effort.
June 12, 2014 at 1:49 pm
JustMarie (6/12/2014)
The DBAs keep my database servers running and happy. In return I keep them informed of things that may impact (or may not) the database servers.Going to have a long running query? Contact the on-call DBA to make sure it's not going to cause problems.
Adding a bunch of data? Contact the DBA team to confirm the space is available.
Security? Oh yeah. Create me some accounts with EXACTLY the minimum access my application needs.
We both do our parts and we work together. The trick is to get the DBA involved at the beginning once I have an idea of the requirements so there's no surprises down the road and all the paperwork is done in plenty of time.
We're not in competition here. There may be some friction when someone gets demanding or inflexible but otherwise it should be a cooperative effort.
+1
I work with DBAs, UI Developers, Web Developers, Application Developers, Report Developers, Data Analysts, Business Analysts, MI teams, Subject matter experts, Legacy Operators/developer, Business experts, Users etc. etc....and dear I say, even Project Managers:rolleyes:, to me, they are all an integral part of the team. The message is, please do the :blush:~~~pissing~~~~ contest on the golf course, Cricket ground, the gym, NOT at work!!!
😎
June 12, 2014 at 2:36 pm
Having lived in both camps, I think the best way to tackle this is through effective change control and especially effective management in general. Managers should be doing their best to be the unbiased referee; removing roadblocks whether they are a DBA, a developer or end-user. A good software manager will do a good job balancing the need to hit a delivery date and product quality. In my opinion both camps are playing to their strengths, usually it's effective management that's nowhere to be found. I wouldn't point the finger at your fellow minion, but your leadership ... or lack thereof.
June 12, 2014 at 3:12 pm
Regarding the Asperger comments:
http://www.nbcbayarea.com/news/local/SAP-Hiring-Tech-Workers-with-Autism-252802471.html
June 12, 2014 at 5:42 pm
This 'war' started before I became a DBA/Dev. I didn't start my career, really, in tech until around 2001 when everything had burst and was already on a downhill. I have to admit, I forget there's a divide called this. I always think Database/App, but I also don't consider myself a DBA, I'm a database Developer these days.
[SOAPBOX]
I'm going to offend... well... everyone. Nothing new there. I'll try to help you laugh along with me though. Because what we're doing is assinine. First, some comments to the thoughts before me here, edited for length, but you can go back and see their posts fully if you choose.
The writing on my soapbox, for those of you curious enough, is simple. "Datastore vs. Data Engine".
Grant Fritchey (6/12/2014)
Personally, I think the blame lies mostly with the DBAs. ... So, they bypassed us at every opportunity.
Yup, and then the old egg-heads would come and thump their Codd books in their faces and ask them if they were insane. Then the developers would wonder if these old guys who don't even have a college course named for their side of the industry could even have a new thought. And it went round and round.
Grant Fritchey (6/12/2014)
At this point, both sides are to blame for not recognizing that it's not code or data that's important, it's the business.
This is key.
Gary Varga (6/12/2014)
A quick (and slightly biased) question: I am a developer whose only community that I am active on is this, so how many of you DBAs are active on developer forums?
That's only loaded Gary for those who feel guilt about not knowing both sides. I started in programming and translated into database. I used to be on experts exchange and those sites (VB6 was big back then, as an idea). I don't bother anymore, and not because of them. See below for more information.
Ed Wagner (6/12/2014)
I do both development and DBA activities, so I get to design it end-to-end. I don't have the conflict of developer versus DBA, as I pick the best tool for the job, and that tool is never an ORM because of the uber-inefficient code they produce.
It's rare to find someone who can mentally transfer well between the iteration methodology of the app tier and rowset methodology of the database engine. That you can speaks well of you. I agree, you need to be able to see the full picture of the expectations to make the determination of where filters should be applied vs. sorting vs. aggregating. The conflict arises from this.
John, I'm not singling you out in particular, but you made a lot of unique points I'd like to address.
John Fager (6/12/2014)
I don't ever like to hear speculation about whether the DBA or programmer needs to fix something.
This would be more helpful in my world if every error didn't start with "Call the database guy and make sure his procs work." That's multiple locations, too, with varying degrees of intensity.
John Fager (6/12/2014)
That said SQL is archaic... It should be aware enough of itself to make decisions about how to manage the physical hardware resources and organization of underlying data for itself.
You're kidding... right? Between VMs, shared spindles in SAN clusters with no visibility, multiple instances on a system using separate Quorums, Heavy Load points during specific periods and avoiding I/O collisions...
Most SQL Engines are intricate enough (Oracle, MySQL, SQL Server, Mongo, pick your poison) that even their own optimizers can get lost on moderate to complex queries when they KNOW where everything is. Throw everything into the automators and you'll have a simple enough system for simple enough constructs. Add in HADR and the rest and you'll end up with a mess.
We're a long way from standardizing Load Balancing of different databases in the majority of RDBMS systems out there. You're talking about taking that idea and going into orbit with it. Yes, my knee jerk reaction is "That's nuts". Because I have had to spend a weekend rebuilding a system for troubleshooting a single one of those items that goes slightly off.
John Fager (6/12/2014)
But what am I supposed to do when I have large amounts of data that require server side paging with user defined, multi-column sorting with dynamic search terms? And even worse, what am I supposed to do when those results map to relational objects that are also returned?
This, John, is a personal favorite of mine whenever I get sucked into the discussion of App vs. Database tiers. You're absolutely right. It's a damned mess. And you're right... but wrong in some aspects.
No, you can't easily manipulate the sorting of the results, and you can't easily paginate. There are techniques to do this at the data layer with reasonable speed, but that's not your point. When you're calling up relational information (subreports, if you like) you have no easy way to control for multiple result sets from the query (Cursor a series of unique selects for dumping 51 result sets out, for example, is one technique), but you CAN grab your ID list, XML it, and ship it back for a single second call for the cache.
This is one of the best examples I know of when the app and database tiers must work hand in hand to get crap to work right, otherwise one side takes on so much of the load that it ends up doing things it shouldn't. Like the app tier trying to filter, or the database formatting the secondary data or turning related secondary data into an XML column for the front end to decompile (which can be find depending on data width).
But yes, this is a great and key example of things that we really need to figure out how to do in a standardized and efficient method between the two layers.
John Fager (6/12/2014)
Our organization now has a policy of writing all applications to be totally agnostic of the underlying data store. We can use SQL, NoSQL, local databases, WCF, SOAP, rest API's, could services or hybrid data stores to get and save our data.
This is an Ivory Tower decision, and looks awesome on paper. And as long as your systems aren't anywhere near their limits, you're good to go. But, as an example, I just recently received a correllated subquery in the select list to deal with an inner join on the outside of a LEFT JOIN. There are methods, syntaxes, and techniques to properly include this in a JOIN in most languages, but they're all different. Agnositic code writing avoids taking advantage of these optimizations particular to the engine... which leads me to standing on this soapbox:
Datastore vs. Data Engine:
What do you expect a database to do? We're on a SQL Centric Site, so I know what the average person here will answer in a rough form. But, ask that of your app developers. No, seriously.
That pain in the *** over the walls who is screaming from the rooftops as an evangelist for the most recent build of ORM-FOM which will take over not only all CRUD duties but even get the damned overnormalized crap in the databases into proper workable entities to apply methods against! It'll even build the methods that when you change a referenced piece of data it'll change the underlying surrogate key for those pesky devs!
That guy. I learned a lot talking to him. It's not a difference of opinions, it's not a databases aren't useful conversation. It's a lot deeper than that. It's a difference of architecture expectations.
Let's back this up a bit. Up above I mentioned that I haven't been on a coding site in 10+ years. This is because I am no longer up to date on the techniques and methods to have anything to add to the discussions. I could read a bit and maybe attempt to keep up to date, but that takes away from my limited time I am willing to spend on self-improvement technically in something that, well, is utterly useless to me. I'd rather go dig into the new SQL 2014 techniques for clustering and snapshots than try to figure out how the next "big thing ORM" is going to completely foul up ad-hoc querying. Nevermind learning the ins and outs of the next .NET library for its ODBC call techniques.
I applaud those of you who work on both sides of the fence, but in my experience most people who do that are one of three types of people:
1) Strong on one side and have enough to carry them on the other.
2) Relatively ancient and have been doing it so long that they helped build the Eniac, so they don't think at that level, they're thinking about CPU buffer transfers.
3) Lacking enough knowledge to do either well. Ignorance is not a failure, you don't know what you don't know. Trying to tackle two specialties leaves you with a significant gap in both.
Anyone not in the above three, and able to describe NUMA configurations without the white paper in front of them AND how the new binary sorting algorithm under the library in 012389313.dll (pulled from thin air, you know what I mean) please go start a company and compete with the big wigs. YOU may be able to create the database system that devs can use without needing to know a completely different skillset.
Told you I'd be slightly offensive.
So, let's go back to our application evangelist. He's working from his viewpoint as to how to get the work done. The database is not a data manipulation engine. It's a bank that keeps what he needs safe between when he needs it. He's got expandable blade caches. He's got N-Tier for load balancing. What he needs is not a data engine that can quickly return user requests. He can row write as fast as his app updates the cache if we're REALLY that worried, but the server's VM mirrored so it won't drop data, relax.
What he needs is a data store that can return app requests so the app can then complete the user request. He doesn't understand why we don't throw more drives at a system that's got high I/O. When he's got high I/O, they throw more blades on it. They're cheap. Drives are cheaper, what's the problem?
Server's overloaded? Split the database in half and shove each half on a different server. Don't worry, my N-Tier will handle the association. That's what it's good at! Just get my app what it needs.
shiver
It works great... right up until it doesn't, and then the database sucks.
This is the problem, or at least one of them. Why? Because think about how they're trained. In schools, in software classes online, everywhere else. They have to design the solution in the softwares they have. If they have a database their either handed something near completed or it's an incredibly simple design, and probably in DB2 or something equally antiquated. Either that or ANSI-SQL safe so they can use 'whatever'.
Tell me how they're supposed to even see the value in the data engine? Any data engine? They treat it like a safe in the wall. Replicate for four years for a degree. Ingraine the habit, the pattern. Maybe show them what a 'complex' database might look like, in case they ever run into one, so they can learn some basic joins and where techniques. Continue to ingraine the pattern as a junior developer who, even in a good shop, is shadowing his boss who's showing him a few hundred techniques for dealing with things in code and occassionally makes a call like "Hey, Joe? Yeah proc xyz is sorting poorly. Can you swap the order by? Thanks." Maybe he sits in on a scrum or two, and never even sees the database guys because they go to the db devs after to review the stories after they've made sure they've got the tech specs right so they don't "waste the DBA's time".
So, our junior, let loose on a new project, has a database he half understands, little to no training in using complex techniques in the engine, has been ingrained for 5+ years in the idea that the database stores his data for code usage, and is now let loose on the world.
Yeah... I get why ORM is there.
If you have this war in your office... if the sides have become entrenched over time... my guess is you have either a blame war occurring, or you're running over each other for this simple reason. The DBAs and DB Devs are trying to get the data engine to work well and efficiently, and the App Devs are horribly frustrated that their datastore is such a pain in the *** to use.
[/SOAPBOX]
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 12, 2014 at 7:25 pm
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???
***SQL born on date Spring 2013:-)
June 12, 2014 at 8:11 pm
Evil Kraig F (6/12/2014)
John Fager (6/12/2014)
I don't ever like to hear speculation about whether the DBA or programmer needs to fix something.This would be more helpful in my world if every error didn't start with "Call the database guy and make sure his procs work." That's multiple locations, too, with varying degrees of intensity.
John Fager (6/12/2014)
That said SQL is archaic... It should be aware enough of itself to make decisions about how to manage the physical hardware resources and organization of underlying data for itself.You're kidding... right? Between VMs, shared spindles in SAN clusters with no visibility, multiple instances on a system using separate Quorums, Heavy Load points during specific periods and avoiding I/O collisions...
[snippet]... Because I have had to spend a weekend rebuilding a system for troubleshooting a single one of those items that goes slightly off.
Here I think you illustrated my point! You spent a weekend sorting out something that is a problem of architecture, physics and math...as a human being trying to trace, track and find out whatever about the problem first. You had to know more about the machine and it's resources than it does about itself.
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. 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 is too little transparency and it takes a very smart, very expensive, and capable guy like yourself to restore balance to the force! It probably shouldn't.
Evil Kraig F (6/12/2014)
John Fager (6/12/2014)
But what am I supposed to do when I have large amounts of data that require server side paging with user defined, multi-column sorting with dynamic search terms? And even worse, what am I supposed to do when those results map to relational objects that are also returned?This, John, is a personal favorite of mine whenever I get sucked into the discussion of App vs. Database tiers. You're absolutely right. It's a damned mess. And you're right... but wrong in some aspects.
John Fager (6/12/2014)
Our organization now has a policy of writing all applications to be totally agnostic of the underlying data store. We can use SQL, NoSQL, local databases, WCF, SOAP, rest API's, could services or hybrid data stores to get and save our data.This is an Ivory Tower decision, and looks awesome on paper. And as long as your systems aren't anywhere near their limits, you're good to go. But, as an example, I just recently received a correllated subquery in the select list to deal with an inner join on the outside of a LEFT JOIN. There are methods, syntaxes, and techniques to properly include this in a JOIN in most languages, but they're all different. Agnositic code writing avoids taking advantage of these optimizations particular to the engine...
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.
The junior or non-SQL expert developers don't ever work directly with SQL or Entity Framework. They don't even have direct access to the code that handles it. The team sets up interfaces for both the objects and the queries. That way, most devs don't have to think about what type of data store is implemented, nor does their business logic or processing need to worry about. They just call a service locator and ask for the IGremlinsRepository. Their code doesn't even need to know what the implementation of the repository is. They don't even know what class will be returned, just that it is an IGremlin or a list of IGremlins. Then they can access all of the methods and properties for their Gremlins.
Meanwhile the app developer that specializes in SQL and understands that better can switch out repositories and implementations behind the scenes. They are registered at run time instead of design time, perfectly optimized for SQL, cloud storage, off-site web services or whatever each repository is setup to use.
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.
Viewing 15 posts - 46 through 60 (of 79 total)
You must be logged in to reply to this topic. Login to reply