Is there anyone can tell me if the following statement is true?



DBA are not experts on SQL. So they are not programmers and can't always
answer programming questions.



The example of programming questions that the DBA refers to is "What is the
function in SQL that works like DECODE in Oracle?"



I just try to understand what the DBA's responsibility is in general.

SOME DBAs are not experts on SQL. SOME are not programmers and can't always
answer programming questions. GOOD DBAs should be able to answer most SQL
programming questions or know how to find out the answer if they don't know
it.

> The example of programming questions that the DBA refers to is "What is
> the
> function in SQL that works like DECODE in Oracle?"

To answer that would require knowledge of both databases. I would expect any
half-competent SQL Server DBA to know what a CASE expression is but that
doesn't mean they would also know that DECODE is a similar function in
Oracle. Many DBAs would only be proficient in one or other product.

--
David Portas
SQL Server MVP
--

"N" <kpnid@hotmail.com> wrote in message
news:cjs9ee$s8i$1@mozo.cc.purdue.edu...
> Is there anyone can tell me if the following statement is true?
>
>
>
> DBA are not experts on SQL. So they are not programmers and can't always
> answer programming questions.

Sometimes.

I have to struggle with syntax at times (those inner joins still get me :-).
But I'm probably the most experienced by far in terms of how to keep our SQL
Servers running 24x7.

I know other companies where the DBA is expected to design the schema, write
the code, etc and they don't really worry much about the workings of the
server itself.

I think the best DBAs try to know as much as they possibly can.

>
>
>
> The example of programming questions that the DBA refers to is "What is
the
> function in SQL that works like DECODE in Oracle?"

I'd argue that a decent DBA could at least answer that. Know the syntax off
the top of their head, maybe not...


>
>
>
> I just try to understand what the DBA's responsibility is in general.
>
>

"Greg D. Moore \(Strider\)" <mooregr_deleteth1s@greenms.com> wrote in message news:<YKn8d.266414$bp1.177861@twister.nyroc.rr.com >...
> "N" <kpnid@hotmail.com> wrote in message
> news:cjs9ee$s8i$1@mozo.cc.purdue.edu...
> > Is there anyone can tell me if the following statement is true?
> >
> >
> >
> > DBA are not experts on SQL. So they are not programmers and can't always
> > answer programming questions.
>
> Sometimes.
>
> I have to struggle with syntax at times (those inner joins still get me :-).
> But I'm probably the most experienced by far in terms of how to keep our SQL
> Servers running 24x7.
>
> I know other companies where the DBA is expected to design the schema, write
> the code, etc and they don't really worry much about the workings of the
> server itself.
>
> I think the best DBAs try to know as much as they possibly can.
>
> >
> >
> >
> > The example of programming questions that the DBA refers to is "What is
> the
> > function in SQL that works like DECODE in Oracle?"
>
> I'd argue that a decent DBA could at least answer that. Know the syntax off
> the top of their head, maybe not...
>
>
> >
> >
> >
> > I just try to understand what the DBA's responsibility is in general.
> >
> >

The DBA in our company is responsible for managing the server - backup
schedules, creation of new databases, permissions on those databases,
and other scheduled jobs.

We, the programmers, provide update scripts for changes we wish to
have made to the live systems. After these scripts have been reviewed
(after a particularly bad experience of the "script from hell" running
on our live server) by at least one other developer, the DBA either
schedules the script to run out of hours, or performs the update
immediately, as appropriate. The DBA is competent to read/review the
SQL himself (most of the time), but doesn't necessarily have to know
the intricate detail of the schemas involved.

The other task that the DBA is involved in is preparation of views for
reporting/MI purposes. Here, more skill and knowledge is required
concerning the schemas involved, but there are also experts on the
individual schema, who the DBA can go to when necessary.

But thats just the way it works here. There are as many different job
descriptions for DBAs as there are DBAs, so far as I've experienced
these things.

"Greg D. Moore (Strider)" <mooregr_deleteth1s@greenms.com> wrote in message
news:YKn8d.266414$bp1.177861@twister.nyroc.rr.com. ..
>
> "N" <kpnid@hotmail.com> wrote in message
> news:cjs9ee$s8i$1@mozo.cc.purdue.edu...
> > Is there anyone can tell me if the following statement is true?
[snip]
> >
> > The example of programming questions that the DBA refers to is "What is
> the
> > function in SQL that works like DECODE in Oracle?"
>
> I'd argue that a decent DBA could at least answer that. Know the syntax
off
> the top of their head, maybe not...
>

I'd have to disagree with you there, unless your answer is short for:

"Given an explanation of what DECODE in ORACLE does, a decent DBA should be
able to describe how to accomplish the same effect in T-SQL (or explain why
one wouldn't want to use T-SQL for that)."

in which case, I mostly agree with you.