Are the posted questions getting worse?
- Lynn Pettis - Tuesday, July 18, 2017 12:52 PM
Yes it does.
Brandie, kudos for asking the question. Three of 15 is 20%, which, given Jeff's observations, isn't horrible. I know that sets the bar pretty low, but asking such a simple question can really save you time. It says a lot about the person claiming to have 10 years of experience. Or is that an aggregate that really means "1 month of experience 120 consecutive times" or something similar? 😉
- Ed Wagner - Tuesday, July 18, 2017 1:30 PM
I'm in Jacksonville so I'm not an out of state call. I just know I have a backlog of recruiter messages on LinkedIn that I haven't had a chance to respond to. I don't actually have clue what positions they're looking to fill just yet.
- Brandie Tarvin - Friday, July 7, 2017 4:48 AM
what you are saying there is what scares me about most of the DBAs I've known (I had the same problem with SysAdmins).
While I'm an engineer, not a DBA, while I was working I was expected to be able to build instances and copies and recovery mechanisms and to create sufficient reduncancy, and to ensure that disaster recovery plans worked. I tested them, for heaven's sake, which is more than most DBAs did, and actually successfully executed them for real (on customer sites) a couple of times, which is more than any "pure" DBA I've known ever did.
If the DBAs of this world all met Jeff's standards and the Developers all met mine we'd have no problems at all. Sadly, the world isn't like that.
But Brandy, from what I've seen of your posts, you are a pretty competent developer DBA, not just a non-developer DBA. So stop pretending that that's not one of your skills, that you're over-specialised and want to be a develpment-incompetent DBA, and accept that to do a decent job a real DBA like you has to be a good developer too and that that's the track you are on.Tom
- Steve Jones - SSC Editor - Friday, July 7, 2017 8:59 AM
That's OK, Steve - I now know that I should never attempt tp acquire a job at RedGate - you people are too damn sloppy, you don't care about being accurate. I guess that's not the impression you want to give, but you just gave it.
Tom
-
I wonder if anyone can explain me the difference between DBA and SQL developer.
I clear terms, please.
I mean - is a DBA expected to do the job all manually? Being available to address any sudden issue 24/7?
Well, it would be a worst form of slavery.
So, being a DBA, you have to develop scripts performing certain tasks, and there is a good chance most of those scripts would be in SQL.
And if you need to fix something in a DB design, or tweak an index - you better script the changes and submit them to the version control system used by the shop. Otherwise those errors in design can come back after one of future deployments.
On another hand - is an SQL developer allowed to write the code without considerations about memory use, indexing strategy, locking, parallelism, other "DBA things"?
Well, that would be a lousy developer producing lousy DB solutions.
Which would require attention from a DBA, who would need to deploy the fixes straight on Prod, with no testing, no QA, with all the bunch of possible nasty consequences, if a small typo sneaks into the fixes.
Well, we've all seen a lot of this.
But is it what we want to see as regular practices due to artificial separation of DBA and SQL DEV positions?
_____________
Code for TallyGenerator - Sergiy - Wednesday, July 19, 2017 1:53 AM
Simple answer:
The Developer, is usually employed by the software vendor; he creates the (layout of the) database: which data goes into what tables, how the data in the tables is split into columns, how columns in different tables are linked by (foreign) keys, what code is run regularly to end user queries...the list goes on, but you get the idea. The database, once sold, is then handed over across a period of X weeks to the DBA.
The DBA is employed by the software purchaser (but sometimes by the vendor instead) ; he will look after the ongoing security, storage, performance, high availability of the client's data. Typically a DBA will harden the environment (or arrange for other areas of the business to do this) so that his nightly callout is minimised. I personally last worked in the early hours about 5 years ago. He may also find, depending on the quality of the vendor, that a piece of code, written by the Developer, does not function well, flag this up with the vendor, and find that they only tested on 10 rows of data, not 1 million, only 2 concurrent live connections, not 200 simulated ones. Generally they will perform re-writes in ongoing versions - but on rare occasions the DBA may end up doing this.
There IS some overlap of the two functions, but this usually only occurs in the cheapest end of the IT market, the kind of company that cannot afford to split the two functions.
- Jason A. Long - Tuesday, July 18, 2017 1:56 PM
Operational DBA. Day to day production & dev support. Basically making sure everything is working in the morning, then supporting the Devs and the users when they think they find an error in the system. Security, backups, jobs, need to know T-SQL. You know. Basic DBA stuff.
So tell me, Jason. How do you get the current date and time from SQL Server? @=)
- TomThomson - Tuesday, July 18, 2017 7:06 PM
That's sweet of you to say so. I really do need to dig more into .NET and CLRs (which I know a smidge about and that's it). But give me a T-SQL project and watch me whip that puppy into shape. I'll even over-engineer it for you before I realize there were 10 easier ways to do it. @=)
- Sergiy - Wednesday, July 19, 2017 1:53 AM
In our environment, SQL Devs aren't just SQL Devs. They're just plain developers who need to know .NET stuff, powershell (sometimes), and how to build application layers, deal with middle-tier servers, etc. SQL Development usually consists of them calling T-SQL through web services or occasionally writing stored procedures and functions to backup what they're coding as a front end interface.
Then again, we have a small shop and the DBAs are all-purpose around here. We're expected to do production support, development on non-application-related items (and sometimes develop the stored procs & functions FOR the Devs), do schema design, build SQL Server instances and upgrade servers, take care of security and backups (including NAS shares and server shares), maintain performance, do some SSIS development (fortunately we don't have to do reports anymore except for the occasional one-time CSV export), and essentially "solve all problems" the users and Devs might have with the system. So I get in a little BI work, a little data warehousing (I designed ours! @=), OLTP stuff, and everything else that someone can convince the boss to make our team do.
-
ACK! DILBERT!! This morning's cartoon, it's like it was written for us...
- TomThomson - Tuesday, July 18, 2017 7:43 PM
And now, to continue stirring the pot...
:hehe:
TBH, I see exactly where Steve was coming from in response to the both of us. If it were a *real* interview and someone, in all seriousness, came back with either of our responses, the odds are quite high that they're going to be a pedantic pain-in-the-...butt. The sort that, while there is a use-case for having one around, is a very specific use-case and they'd more than likely end up trashing the team.Now, me, in my response, I was building off your (Tom) response and letting my smart-...butt side have free reign over my typing.
Mostly because:
A) This is the water-cooler thread, I can be a smart-...butt here and get away with it and not have to worry (too much) about someone taking my answer seriously
B) It wasn't like Steve was actually interviewing us for a job, so again, I can be a goof and give a completely non-serious non-answer (you weren't interviewing, right Steve? I haven't shot down my chance to work at RedGate, right?)OTOH, I also would have had to answer, truthfully, that off the top of my head I *don't* know how to solve fizzbuzz in T-SQL. Or at least I didn't before it came up here. But I'll probably forget long before my next job interview (far in the future may it be.)
- TomThomson - Tuesday, July 18, 2017 7:06 PM
I think what this is a case of is perception. People hear "developer" and immediately think of the people banging out code all day long crafting the next billion-dollar application or the next Angry Birds. People here "DBA" and tend to think "what the heck do they do?" without thinking about the fact that there's a lot of crossover between developer, DBA, and sysadmin. I think if you sketched up a Venn diagram of the three, you'd have a slim bit of crossover between sysadmin and developer, a fairly decent crossover between DBA and sysadmin, and a moderately sized crossover between developer and DBA. The center would be just the tiniest little spot as I suspect people who are all three are a rare and exceptional breed.
After all, if you think about it, how many of us who call ourselves "production DBAs" have banged out some T-SQL to do something (development) or worked with a developer to troubleshoot a possible database issue? We've done development work.
How many developers have had to work on indexing strategies, or setting up Agent Jobs for their application, then had to hand off implementing them to the "production DBA" to be set up in production? Welcome to the DBA side of the fence.
And how many of us have had to deal with not only patching SQL, but handling the OS as well, up to and including setting up a Fail-Over cluster? Welcome to the sysadmin world.Sure, I can't develop T-SQL code to do something as fast, or as elegant, as a "pure" developer, but I'd bet I can get there (same thing applies to you, Brandie,) and I doubt I could get a Windows Fail Over Cluster up and running as fast as a "pure" sysadmin, but I could get it done. The trick is always knowing that you don't know some things, even if you don't know what you don't know, and more importantly, being willing and able to admit not only to others, but to yourself, that you don't know something. Then either setting about finding someone who does know and getting help, or learning about it yourself, or both.
-
OK, is anyone else running into this?
I post a comment / reply here, it posts fine, but rather than taking me to the response (with the previous posts above,) it *ONLY* is showing my post.
Now, it could be weirdness brought on by the office network, and I don't have another browser here to test on, but it's certainly annoying... - Sergiy - Wednesday, July 19, 2017 1:53 AM
There isn't a precise definition. It's very much a local thing. Different businesses define it different ways. I'll use myself as an example. I had worked as a developer, then moved into a pure DBA role. Next job, back to development. Laid off the week before 9/11, when I finally got a job offer, at an incredibly reduced salary, it was as a DBA. However, at the time, DBA just wasn't my passion. I still loved development. About three years into the job, I started looking at switching to the dev side of things. My team liked having me around for some reason, so we created a new role, Database Developer. I was responsible for database design, T-SQL coding, standards in that area, deployment, deployment processes, all sorts of stuff (including tons & tons of query tuning). I left behind OS-level access to the production servers (and never missed it, despite still being on call and dealing with outages at night, etc.), management of the HA & DR side of things. I was still effectively a DBA, but I worked a lot closer with the dev teams (some of whom objected, others loved it). However, it was something only a larger shop could have provided. In a smaller environment, you'd never be able to specialize like that. I'm not sure this helps at all, but it was the situation I was in.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore RooseveltAuthor of:
SQL Server Execution Plans
SQL Server Query Performance Tuning - Sergiy - Wednesday, July 19, 2017 1:53 AM
I consider myself a SQL developer, although, my current title is development DBA. The responsibilities are basically the same: help front-end developers to work nicely with the database. That means that we need to code complex procedures, review the ones made by developers, do db design, work with production DBAs to create index strategies, etc.
I know that I could do some production DBA work, but I can't be as reliable as our production DBA team.
I believe that this has been posted in multiple places over time:
https://www.brentozar.com/sql/picking-a-dba-career-path/
http://www.sqlservercentral.com/articles/Administration/dbaroles/517/
Viewing 15 posts - 59,296 through 59,310 (of 66,712 total)
You must be logged in to reply to this topic. Login to reply