T-SQL for the Analyst
-
Hello. A few months back I left the DBA/Programmer ranks at my institution and crossed over in to the analyst ranks. I've been fortunate enough to be able to continue to work with an SQL Server by writing scripts, creating objects, and creating DTS packages. This kind of dual role function is practically non-existent where I work.
My problem is that my DBA is starting to make noises about how I'm more of a programmer than an analyst and how I should be in his unit. Not a good thing.
So, my question is: can the community out there provide me with examples of people and places that you know of where analysts are also allowed to work with T-SQL? I realize that I'm probably doing more than an analyst should do in creating objects but that's due to the skill level of the DBA and something that I've consistently been arguing that I should not be doing. Real world examples could go a long way in stopping these annoying statements before anyone takes them too seriously.
Thanks.
Everett Wilson
ewilson10@yahoo.com -
Sure.
Some years ago we developed a data warehouse incrementally, starting with a desktop as proof of concept, and growing over time. It's now very large, and wildly successful, but largely built from homegrown tools and delivered over an Intranet, which works great for 95% of the users.
It does not work great for analysts digging into new areas, since parameterer driven canned reports on the intranet are inherently limited.
So early on we took our new analysts and said "you will be more successful if you learn SQL". And a bit more quietly "it never looks bad on a resume either" as most of these were young and aggressive.
From my viewpoint it has worked well for the majority of them. Some are better than others, but the ones that learned became better analysts, they understood the inherent nature of the data better, and perhaps the best aspect is that the working relationship with our programming staff became FAR more productive.
Picture a request for "I need a report on X" that involves a very complex query beyond their ability. In a classic environment, the programmer needs to not only write it, but wrap it up in a report or web page, go through the overhead of source control and promotion to production. Instead, if this is really a more one-shot thing, they can do a simple version and say "here". With that as a starting point the analyst can polish, change, revise. Analyst gets something quicker, programmer does a lot less work, and if it turns out to be a good, reusable tool the programmer can take it back and add it to the intranet. [By the way, I use the term "programmer" broadly, our DBA types and classic progrmaming type are integrated into the same group; I think the wall between DBA's and programmers many sites have is a bad thing.]
Now there is a danger -- stupid run-amok queries, bad joins that return nonsense are two that come to mind. But from what I have seen, insulating analysts behind fancy front end tools rarely solves that problem in an ad hoc environment. It just makes them feel more protected.
We also did some things to push this along, which I think was very important. Our Intranet, production, canned and polished queries produce nice reports and graphs, but they (almost) all have a button that says 'show query'. That query can then be cut and pasted into Query Analyzer or Excel and run manually. It's a great teaching tool, and also lets them do simple customizations, like different sort orders or more complex selection criteria, without really knowing much about the guts of the query.
We also forced them off Access. The difference in SQL was too confusing (plus I'm convinced Access is a virus that should be stamped out for other reasons). And we gave them a "sandbox" database where they can create tables and stored procedures, isolated and with some tools to watch for too-big data, stale data (they are told it is for temporary storage), etc. One need we found early was for them to upload spreadsheets, like customer selections, for some project, and use it in joins.
So at this point, the analysts are more empowered, my programmers are more productive, and I think our unusual setup is working great.
-
Well, I don't work in the IT business at all. My main duties are the asset management for our insured persons. So, no position that usually deals with creating enterprise databases or maintaining servers. However, since SQL Server is my passion, I am sa to the servers and usually asked when things go wrong. But I also do think, that we are exceptions to the rule. Talk to your DBA, prove your knowledge but without appearing arrogant when you realize that you know more than him. That way worked for me, so they made me sa.
Btw, my company is moving into a direction where they want such "power-users" like I think you are in our departments. That way those users can take care of the belongings of the single departments ( that is, department-wide development) and take the stress from our IT department.
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Stupid question, but what are the fundamental differences between a DBA, an Analyst and a Programmer. My company is small enough that there is no distinction between various types of database work.
Bob
SuccessWare Software -
If that's not a rhetorical question, I'll take a shot.
At our company an analyst tends to be from a business background, not technical. Their charge is to analyse business processes or data, and the data is clearly a necessary part. Frequently it is a transition job up the ladder to Finance, Sales or management.
A programmer (SQL or other) tends to focus on data, and (at least in terms of training and background) tend to have relatively much depth in the technical aspects and relatively little in the business.
And for a DBA, their background and focus is often on the physical aspects of the database (and lots of other things) as opposed to programmers who should be concentrating more on the logical. I do not mean to imply the DBA does not do both, but rather that programmers by and large ignore physical aspects (file groups, even indexes, etc) and concentrate on logical, but a good DBA has to do physical.
Yes, at small companies, many hats are involved.
-
Not at all rhetorical. I need to make some decisions regarding career path and I wondered how more formal definitions fit with my personal goals.
THanks.
Bob
SuccessWare Software -
Ferguson and Frank, thanks for the stories. I have to say that the model Ferguson is working with sound smart and worth taking big picture ideas from.
I have to add, though, that I find myself in a situation where I'm going to be seeing a lot of MS Access. Not only do the web people here know little about web standards and canned reports but the quasi-DBA person loves Access.
Maybe I should add as a mid/long term goal getting permission to adminster the SQL boxes a la Frank.
Thanks again.
Everett Wilson
ewilson10@yahoo.com -
quasi-DBA person loves Access.Run away as fast as you can.
Access is an evil blight upon the universe
I will light a candle for you
Bob
SuccessWare Software -
Bob, I'm just catching up on my updates and came across this. I will respectfully disagree with you. Access, like nuclear power and horse manure, has its uses even if you don't want to get any on you.
I routinely use Access connected to SQL databases to work with data that needs to be converted. It's the lazy man's way to see how things will work, quick and dirty.
I'll assure you I've given up developing in Acces but I still keep it in my toolbox for emergencies.
Don
-
With today's post I just noticed this thread for the first time. Regarding "analysts", I think it is important to specify what it is an analyst analyzes. At my company, there are many different kinds. Just in I.T., we have:
- Business Analysts - application support for functional department coupled with data analysis.
- Support Analysts - Helpdesk (1st tier support)
...and me, a Systems and Database Analyst. I was originally a systems analyst that took over DBA, some programming, some design, and DML assitance for report writers. Hence, the addition of "database" between systems and analyst.
Anyway, to contribute to the answer to the original question, Yes. There are definite reasons why someone with an '%Analyst%' title would be using SQL and administering servers.
As far as MS Access goes - I have to give it "bang for the buck" kudos. It's one of the most powerful tools I can think of for $100 (ignoring SQL Developer's edition for $50, of course). And, without it, our Business Analysts would need a lot more DB assistance.
-
Systems Analyst seems like it comes pretty close. I like that.
On Access, I'll agree it's good for a quick solution and great for end users to develop their own applications. Heck, I push it as a solution for end users and try to get anyone interested to learn more. I also know that there are lots of MS Access VBA people out there that love the program.
I, however, am in the classic situation of working wtih applications that are slow and cannot be scaled up and/or out. And of course it's both queries and VBA scripts that are laying around that now need to be moved.
Everett Wilson
ewilson10@yahoo.com -
Don,
Obviously, my tongue was so far in to my cheek I nearly bit it off.
My problem with Access is that it too often people think that it works so well for their small tasks that they try to scale it up. Then BOOM. For desktop work I think it's fine. As soon as you try to run it over a network, even a small peer-to-peer, I think it's trouble waiting to happen.
Just my 2 cents.
Bob
SuccessWare Software -
Do you enjoy numbers and puzzles? Risk analysts require advanced SQL skills and do pretty well financially. Often you also need a masters but you can do pretty well as a data analyst in a risk management department. It pays substantially more than a data analyst in an IT department and is admittedly more interesting. If you are in the US(in particular)...I imagine the demand is starting to increase with rising interest rates too.
Do I speak from experience? Yes, in fact I am in the opposite boat. I would rather be in more of a programming/dba position than an analyst position, though it is challenging nonetheless. I am trying to make this happen.
btw - agree with Bob - Access could not handle 95% percent of the work we do. In addition IT departments in the last 4 companies I have worked will not support it. (One was downright mean about it!) Probably for that very reason. Even on a tiny budget i would use MYSQL over Access anyday.
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply