June 3, 2014 at 12:07 am
Comments posted to this topic are about the item Developing with SQL Server – What must a beginner know?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 3, 2014 at 6:03 am
Awesome! I to am a "Professional" beginner although I have considerable experience but yet I am seeking improvement. I look forward to future articles and presentation on this platform. I hope to one day achieve certification!
June 3, 2014 at 6:27 am
To my eyes:
1- Willingness to learn
2- Open mind to a new way of coding (a programmer think procedurally instead of sets)
3- Understand that there's no "one size" fit all solution
If you got those 3, ask me what you want, it will be a pleasure to help. Otherwise there's Google for you and (D)on't (B)other (A)sking me.
Those who have these skills have learned (or are learning) a few trick in SQL and are more autonomous and more autonomous and I can let them go alone for day to day tasks.
Those who still argue negatively about SQL that it's X, Y, Z bad, slow, does not work like A, B, C coding language, what ever wrong you want to throw, never learn and do the same mistake again and again up to the point that some have mandate their superior to avoid giving them any SQL tasks. (To my pleasure, tasks are given to those you are willing to learn and it's less a burden for me and the software runs better)
The clash is astonishing between the two groups.
June 3, 2014 at 6:35 am
Good list for "absolute minimum". The technical test for the job I have now pretty much covered exactly those things. My boss was looking for someone experienced but wanted the test to be short and useful. Apparently it's enough to filter out enough people. He only had 2 suitable applicants after all was said and done.
June 3, 2014 at 6:53 am
Minimum skill?
For me I more interested in the aptitude rather than the supposed skill set. If someone is skilled but trigger happy/ slap dash then mistakes will be more common and more extensive. But a person who is willing to learn and wants a robust solution then it will be easier to get to a proactive role than constant fire fighting.
June 3, 2014 at 8:51 am
I would add that they need a good understanding of threading. There is no difference between running multiple threads in an application and multiple users in a database. It's just not as obvious.
June 3, 2014 at 9:25 am
cmiller66 (6/3/2014)
I would add that they need a good understanding of threading. There is no difference between running multiple threads in an application and multiple users in a database. It's just not as obvious.
Exactly. Perhaps referred to a concurrency?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 3, 2014 at 10:39 am
One issue I have encountered quite a bit recently is with the ability to think and write in non-procedural languages and to employ functional programming techniques. Thinking procedurally and state-wise evidently leads to terrible SQL involving cursors, loops, and multi-stage queries against table variables and temp tables, from what I have seen of late. Having a "no cursors" culture doesn't prevent this -- it just leads to more loops and multi-stage queries against intermediate results.
Another issue that I have seen a lot of lately is with not understanding how to use date/time functions, which also seems to relate to the above. This leads to coding atrocities involving converting dates and times to strings, applying T-SQL's feeble string functions, and then converting back. Yuck!
I think it is something like learning to draw. If you are verbally oriented, the non-verbal processing involved in drawing can make it seem nearly impossible to do it well. You have to learn to engage the part of your brain that does the non-verbal or, in this case, non-procedural/functional problem solving. Until you do, you may be limited to writing bad SQL and making poor excuses for it.
June 3, 2014 at 11:12 am
I'm new here but Gary's editorial caught my attention. I think this discussion is really useful.
Gary has identified "Development" and "Administration". My suggestion is that you want another category as well: "Analysts" (or chose another title if you prefer) = Those who work with "requirements" and try and create something which both the business users and the Developers understand. That's what I see myself as.
If you have an "Analysts" category then they should have:
*) Set theory
*) SQL and RDB theory (what makes a database "relational"? Programs communicate with the database using SQL)
*) SQL queries, especially SELECT
*) SQL queries; Insert, Update and Delete and just a hint of what is a stored procedure
*) Security model
*) Entity Relationship models (or any other name that suits you)
All of this knowledge can be at a very high level. The objective is not to replace Development or Administration, but to be able to have a sensible conversation with Development and Administration and recognise when misunderstandings are occurring. I think what I'm asking for is that they should "know enough to recognise what they don't know!" (or that they should be getting advice about).
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
June 4, 2014 at 7:24 am
Those bullet point should have links to refer to read related materials.
June 4, 2014 at 11:22 am
Sureindran Nadesan (6/4/2014)
Those bullet point should have links to refer to read related materials.
Feel free to offer suggestions 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 4, 2014 at 6:53 pm
Gary's list is very good. But I think it leans too weak and too strong.
On the administration end, if backup and restore and executing a script are bare minimums, security is actually too complex. If you are small enough to not have a senior DBA, don't expect your junior DBA to have a strong knowledge of security. Trust him to keep things running without restarting the server on a daily basis.
I am a decent SQL developer and handle a lot of query tuning. I would never expect a developer to understand SQL's security model, even a very experienced one. I would expect semi-complex queries though.
When I am interviewing I use a simple litmus test question for both junior candidates.
- Show me from a few simple tables the customers who ordered last year but do not have an order this year, and how much they ordered last year.
- Tell me some differences between delete and truncate.
These two tests show me the Set Theory and SQL Query Processing Logic without sounding scary. As long as the query gets written without a cursor I don't care what the junior guy shows me. Just get close to an answer. And I'll give credit for anything close to "delete can be filtered, truncate cannot", bonus points for anything beyond that.
Brian
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply