Core T-SQL

  • TomThomson - Friday, November 10, 2017 8:30 PM

    Jeff Moden - Tuesday, November 7, 2017 7:08 AM

    To me and as you say, there is no question in my mind that a good DBA not only knows what could be done but how to dig up enough information and the correct syntax to do it.  However, there is some core functionality that should be known to actually be a good DBA of virtually any type possibly excluding only those so-called "Pure Systems DBAs", especially in today's environment of "consolidated employee footprint".

    For example and, again, IMHO, if a DBA or Developer has to look up the syntax to do a simple joined UPDATE between two tables, that person hasn't worked with SQL Server enough to be called a DBA or even a Developer.  Certainly, you should know at least 2 of the many functions that will get the current date and time and what the differences are and you'd damned sure should be able to properly describe the differences between a FULL, DIF, TRN, and COPY_ONLY backup and how each of those file types comes into play when doing a restore.  To your point, I wouldn't expect a DBA to be able to write code off the top of their head to do such a thing but they better know the rest.

    Any DBA or other person that claims 10 years of performance tuning of queries, stored procedures, etc, had damned well better be able to describe at least Clustered and Non-Clustered indexes to a great depth.  DBAs don't necessarily have to know those to such a level unless they claim performance but they should know what a FILL FACTOR is even if they can't write a CREATE INDEX or ALTER INDEX off the top of their head.

    If someone claims skills in stored procedures and other SQL Server code objects, then they better know a whole lot more than simple SELECT, INSERT, UPDATE, and DELETE and I expect them to know a great deal of syntax off the top of their head.

    Remember that when hiring and interviewing that the position of DBA and Sr. DBA aren't rookie positions and while I certainly and high value the ability to science things out, you do have to know the core items and a whole lot more even at the code level.

    I totally agree , Jeff. 

    What I was concerned about was a few posts which seemed to be heading for the extremely silly idea that a DBA or Developer writing T-SQL should know the detailed syntax of everything available in T-SQL.  That idea is I think about as silly as the idea that DBAs and T-SQL developers don't need to know a lot of syntax.

    I think there are a lot of things where both DBA and developer should know the detail (updating through joins is an obvious example, getting the date and time is another, using Isolation Levels properly is another).   Both have to know what clustered and non-clustered indexes are and what they are useful for and how they work, and understand how non-clustered indexes differ depending on whether the target is a heap or has a clustered index, but that isn't syntax.   Of course they should both know how to create indexes at a basic level (maybe having to look up the syntax for adding non-key material to the index is acceptable - I have created such an index only 3 times in the last 18 years - or maybe someone working on a collection of databases where such material is often needed might need to learn it).  And of course they should know about the different types of backups and how to use them, but provided they have built the necessary scripts they probably don't need to remember all the detailed syntax; but of course if they haven't scripted the recovery stuff (or don't run the recovery stuff regularly and check that it actually works) they are nowhere near up to scratch.

    But during the 9 years I worked with SQL Server 2000 I never learnt how to write an Extended Stored Procedure with main content in C++.  I got the impression that some people writing here might think that disqualified me as a T-SQL developer, hence my earlier post; probably it was a reply to the wrong person (Eric), some earlier posts had got me somewhat disturbed and I think I misinterpreted his as being more of the same.

    Ah... I see now, Tom.  No... I don't expect people to write code to do everything in T-SQL.  I'm just totally gob-smacked that people say they'd still hire someone for a senior position even if they don't know how to get the bloody current date and time in T-SQL.  It's no wonder that the title "DBA" has become almost a joke.  And I totally agree that someone that has written scripts to do their backups isn't necessarily going to know the exact syntax and I wouldn't ask such a question.  Hell, I don't remember that myself for the same reason.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

Viewing post 106 (of 106 total)

You must be logged in to reply to this topic. Login to reply