November 22, 2013 at 4:41 pm
pdanes (11/22/2013)
Biggest skill I need is how to find stuff on SQLServercentral.com
😀
November 22, 2013 at 6:18 pm
I think that a basic level of proficiency should include implementing structured and unstructured error handling.
About the apply and the windowing functions, or OVER CLAUSES as some developers call them, I believe that most of that functionality is implemented at the client application., the same as ORDER BY clause.
November 22, 2013 at 7:04 pm
ojrodriguez (11/22/2013)
I think that a basic level of proficiency should include implementing structured and unstructured error handling.About the apply and the windowing functions, or OVER CLAUSES as some developers call them, I believe that most of that functionality is implemented at the client application., the same as ORDER BY clause.
BWAAA-HAAAA!!!! First of all, the article isn't about "developers". It's about "Database Developers".
Shifting gears a bit, why do so many people assume that where there's a database, there's a client application? And when there is an application available, why do so many people think that most of the processing is done by or can be done by the application?
On every large system I've had to work on, the "application" is just the proverbial tip of the iceberg. Yes, I agree... it probably consumes the most CPU and other resourses but the processing rowcounts are nearly trivial compared to the batch processes that run behind the scenes.
As someone said to me, "If you try to take ROW_NUMBER() or ORDER BY away from me, you'd have to pry them from my cold dead hands before I'd let you." 😀
If a "Database Developer" doesn't know about the windowing functions, APPLY, and ORDER BY, then they're not a "Database Developer" nor even much of a front-end Developer "with some knowledge of SQL".
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2013 at 10:35 am
From my point of view a competent database developer knows his/her limits (= when a given scenario would require to leave his/her "comfort zone") together with understanding what concept would provide a scaleable and "useful" solution to a given scenario. The level of competence would be equivalent to the "size" of his/her comfort zone 😉
I'd also say it's not only a question of what SQL techniques someone knows but also if that person knows when to use it and what alternatives might be available together with the ability to explain why a specific technique has been chosen (e.g. the usage of table variable instead of temp table or vice versa).
I'm not a big fan of developers immediately using new features (just because they're "cool") without getting a deeper understanding of possible side effects (e.g. MERGE in combination with INSTEAD OF triggers or the bugs that existed in the "early days of MERGE").
Neither would I prefer working with a developer knowing the syntax of all that stuff that's been mentioned before but still uses RBAR techniques all over the place where it's not required.
November 24, 2013 at 6:46 am
Jeff Moden (11/22/2013)
From the article:
This week I'm curious if we can debate about, and compile, a list of core skills with T-SQL that we think someone ought to understand to be considered competent as a database developer.IMHO, the quote above is a bit of an oxymoron because if all someone has is "core skills" as typically defined by a good amount of the community, then they're not a "competent database developer". They're a partially educated and usually dangerous user.
That may be true - I don't know what the core skills as typically defined are. Certainly I wouldn't regard Steve's list as adequate - for example someone who doesn't unerstand what normalisation is and what the techniques for doing it are is not remotely competent - I don't care whether they know what 3NF is, or any other NF, I just want them to understand things like the representation principle and DRI and anomaly avoidance - if they don't understand those then any normalisation they do risks being very damaging both to data integrity and to performance, and knowingwhat the usual named normal forms won't help if they don't know what the are for and which are appropriate when.
What do I define as "core skills" for a Database Developer? The list is way too long for me type up but I can give you an example. I don't care how long someone has been programming in T-SQL or what kind of "miracles" they think they may have pulled off, if they have to lookup how to use a LEFT OUTER JOIN or a CROSS APPLY, then I don't consider them to be a Database Developer never mind a competent one. As another example, there's a huge difference between someone that has used BCP and someone that has skillfully used BCP. The former is a user, the latter might be a Database Developer.
I think an emphasis on detailed knowledge is probably wrong. I have a different requirement. When someone designs and scripts the schemata, and designs and writes the code, and it all performs superbly and caters for all the nasty things that might turn up in the data or in what users and application developers to do to to it with brilliant error management and defensive programming and properly covers security issues, and they produce and document the design and scripts and code including how the schemata relate to the business rules and anomaly avoidance and how the testing was done and how the whole thing relates to requirements and code and does all that rapidly, and manages to do it without pissing off too many people in the course of getting it done, I don't care whether they achieved all that because they knew all the detail or because they knew what was needed and where to look the detail up. My requirement is that they get it right - for example their testing includes performance testing for extreme throughputs and data volumes, well beyond what is likely to be required in the forseeable future, they do it in time for it to be useful and without making permanent enemies of too many brainless wannabe managers (although that last is perhaps only desirable, not essential). If someone consistently does that, to me they are a competent database developer whatever details they have to look up.
I suspect that I'm not a competent database developer by your definition, because I don't know all the core stuff off the top of my head - I sometimes look things up; for example I still look up the Merge statement sometimes when I use it, because I haven't used all its capabilities all that often yet. But then I never thought that cluttering up my detail memory with stuff that I only use once every few months was a good idea, and in my experience people who do remeber all the detail are usually incapable of stepping back and thinking out of the box, so I don't agree with your definition.
I think that the bar has been set way too low for the position of "Database Developer" or "skilled C#/.Net programmer with good SQL experience" or even DBA. I think that any DBA (system, application, or otherwise) that doesn't actually know what a clustered index is should be banned from using "DBA" on their resume. I think any front-end programmer candidate that can't describe in detail the differences between a "Get" and a "Post" should go to jail for as long as they've been in the business because they've been robbing whomever they have worked for.
We agree on all that. What's the penalty for flouting the ban though? I think it should be a long jail sentence. Not quite as long as the sentence leaving the system open to injection attacks, though. As for the front-end programmer who is confused about get and put, as will as robbing his employer he has probably been causing enormous great security holes in a website whose insecurity harms everyone who visits it.
Tom
November 24, 2013 at 7:41 am
I think the idea of "Core TSQL" isn't unreasonable, but no set of knowlege which is just about T-SQL and not about the bigger picture will ever make a competent database developer.
Obvious things that a competent database must have good knowlege and understanding of include:
1. The relational model
2. Set based thinking, including all sorts of joins and unions and intersections and differences and projections and restrictions
3. Normalisation, including the representation principle(s), keys, DRI, and what it's all for
4. The principles of error management, including avoidance, detection, elimination, containment, recovery, reporting
5. The principles of testing and validation, and its objectives
6. The modularity principle, and its purpose
7. General avoidance techniques for security issues
8. The ACID principle and the various things that the I part of ACID can mean
9. Performance measurement and verification
Then he should understand why items 3,5,6,7 and 8 above, which are actually parts of item 4 above, are important enough to be considered separately; also how items 2 to 9 relate to item 1; and of course how all of items 1 to 9 relate to what he needs to achieve.
Then he should have a good idea of what techiques are used in connection with each item of the above list; and how these items and techniques can be exprssed in terms of T-SQL and the development tools associated with it.
Once he has all that, he needs some more specific stuff: for example what are the indexing structures available, what are their properties, how to they impact the various aspects of performance, restrictions on what can be done with views and CTEs, what constructs are there for temporary relations which other that statement scope.
He very much needs to learn that T-SQL is declarative only in the sense that single statements in almost any language are declarative; it isn't declarative at any wider level, unless he takes enormous care to write it in a declarative style, and if he wants to do that he will have to learn how (and no T-SQL or SQL textbook on the topic exists yet). Otherwise he may think he can do all the nice things mentioned in books/articles about declarative programming and get a shock when he tries. But people not familiar with declarative programming generally don't try to do any of those nice things, and people who are tend to notice very quickly that SQL is not a declarative language any more than C++ is, so maybe this item doesn't need to be on my list.
Finally, he should know enough about T-SQL and SQLServer to find anything alse he needs to know about it by looking at the T-SQL Reference and the rest of BOL and/or all the SQL Saturday records on the web and/or the technical articles (and comments on them) here at SqlServerCentral.com; and enough(*) of the detail that he doesn't spend so much time looking things up that he is not able to develop desins and code quickly enough to be useful. The final essential is that the developer must be very very thoroughly aware of the limitations of his knowlege, so that he doesn't make mistakes through not looking up when he needs to.
(*) people will disagree about how much this "enough" is. I'm not goingt to try to list it. I don't believe it's the same amount for everyone, anyway. Yes, there's some core stuff like the general shape of a select statement and how data flows from one part of it to another, how to express domain constraints in a language like T-SQL that doesn't have the concept, how to write joins in T-SQL, and so on; but how big this core is depends on how quickly people can hanle looking stuff up - people who tend to be slow in finding and understanding detail will have to have more knowlege as part of their core in order to be able to do things at a satsfactory speed than will someone with first rate search skills and the ability to understand a couple of pages of technical detail by skim-reading it.
Tom
November 24, 2013 at 6:39 pm
This doesn't sound unreasonable either but, want to ask you is, what should one add to one's skill set to become an expert?
November 24, 2013 at 6:44 pm
ojrodriguez (11/24/2013)
This doesn't sound unreasonable either but, want to ask you is, what should one add to one's skill set to become an expert?
1. Common sense.
2. Logic.
3. Ownership of a problem.
4. Dedication.
5. Humility.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2013 at 6:55 pm
This is a great idea, judging by the debate that it has generated. May I suggest another topic that could generate some controversial debate also?
I think that it would be interesting to learn what others think of the a list of Best Practices of a SQL Developer.
Thanks
OJ
November 24, 2013 at 7:32 pm
ojrodriguez (11/24/2013)
Best Practices
Actually, that's an oxymoron from what I've seen. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 24, 2013 at 9:37 pm
I am impressed, such wisdom!
November 25, 2013 at 8:26 am
So what minimum T-SQL skills are necessary if you're a DBA, not a developer?
November 25, 2013 at 8:28 am
Jeff Moden (11/22/2013)
Shifting gears a bit, why do so many people assume that where there's a database, there's a client application? And when there is an application available, why do so many people think that most of the processing is done by or can be done by the application?
...
If a "Database Developer" doesn't know about the windowing functions, APPLY, and ORDER BY, then they're not a "Database Developer" nor even much of a front-end Developer "with some knowledge of SQL".
+1 on database developers not needing applications - the closes I usually come to an "application" is SSMS, sqlcmd, bcp, or sometimes SSRS, perhaps with a schedule (SQL Agent, at, Windows Task Scheduler, or third party schedulers) and those are almost always used as simply carriers for SQL or a format file.
I do have to wonder about APPLY - that's just not something I've used much, so I'll take a further look.
As we can see from the discussion, though, there are different "core" sets for different environments - single, small transaction OLTP environments are very different from large aggregate query environments, for example.
November 25, 2013 at 8:30 am
rlortega (11/25/2013)
So what minimum T-SQL skills are necessary if you're a DBA, not a developer?
That really depends how many DBAs there are in your company. If there are many, perhaps the company will want people who are experts in some skills and 'familiar' with others - between many DBAs the whole skillset can be met to an expert level. If your company only has 1 or 2 DBAs you probably need to have skills in the entire feature set.
Ben
^ Thats me!
----------------------------------------
01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
----------------------------------------
November 25, 2013 at 10:58 am
Applying indentation so scripts are readable
Nothing spells a good day at work like reviewing a query containing multiple nested table expressions; all the while, no indentations - everything is blocked on the left margin.
This idea could be out of scope or considered an obvious skill, but boy...it grates my nerves.
:crazy:
Viewing 15 posts - 31 through 45 (of 105 total)
You must be logged in to reply to this topic. Login to reply