March 12, 2014 at 8:03 am
Although I will admit - Core skills, and 'Nice to Have - you will need these skills' - will drive a lot of debate at times.
Kind of like building a data warehouse. You may never be done, as technology and user requirements are ever changing.
And if you wait until you can do the whole thing, chances are you will never get to implementation.
I could easily see several articles, not just 1 huge one which could be quite large.
Some of the 'why you should know this' might be important, especially to a newbie.
March 12, 2014 at 8:13 am
Greg Edwards-268690 (3/12/2014)
...Some of the 'why you should know this' might be important, especially to a newbie.
Perhaps "under what circumstances you would need to know this" might be a good indicator to many too.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 12, 2014 at 8:18 am
Greg Edwards-268690 (3/12/2014)
Although I will admit - Core skills, and 'Nice to Have - you will need these skills' - will drive a lot of debate at times.Kind of like building a data warehouse. You may never be done, as technology and user requirements are ever changing.
And if you wait until you can do the whole thing, chances are you will never get to implementation.
I could easily see several articles, not just 1 huge one which could be quite large.
Some of the 'why you should know this' might be important, especially to a newbie.
The last point you make is roughly how I see it panning out, a paragraph or two per point with good references for those wishing to dig deeper rather than a single humungous article. A digestible article with concise and compelling reasons for each key point. Many developers won't know all of the stuff listed and this format - which encourages cherry-picking - would be more attractive initially and less of a time-thief in the longer term.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
March 12, 2014 at 8:25 am
Maybe it helps to agree on certain roles first and work out an appropriate list per role?
For example, I would see at least these distinctions as useful in writing about required SQL (and by extension) SQL Server knowledge.
Level: Introduction / getting started
* Understanding the basic relational model
* Basic querying (select, order by, group by, joins and sub queries)
Level: Data manipulation / Limited programming
* Point out some modeling features (how to create proper tables, indexes)
* Views
* Procedures
* Updates / Deletes
* Basic understanding of locking and transactions
Level: Programming / Limited administrating
* Most modelling and referential integrity features
* Triggers
* Schema's
* Security / Linked servers
* Advanced SQL constructs (outer clause, CTEs, functions)
* Bulk imports
Level: Advanced programming, Administrating
* Add remaining full modelling and referential integrity
* CLR Integration
* Data warehouse features
* Other enterprise specific features
* Isolation models
* Clustering
There is quite a bit more no doubt, i do not claim to know it all. By designating levels/roles and what it is good for, people can quickly get an impression on what they need to grasp and might be missing out on. It could be the best that can be achieved as few will ever get to work with everything and know it all.
March 12, 2014 at 8:49 am
I guess a differentiation must be made in skills required for administration and skills required for development. We have 15 DBA's and twice that many developers. We are DBA's but we do not develop. We tune at the instance and server level but query tuning is done by the developers, with our assistance.
Of course, we have hundreds of databases on many servers.
March 12, 2014 at 8:57 am
I was thinking that... Developers aren't necessarily untrained DBAs, it's a different skillset not necessarily a 'lower' level.
I'm one of my company's developers and the DBAs are on another team. I get given way more work to do that requires efficient and complex queries with some of the more advanced features than the DBAs do, but if you ask me to deal with log file corruption or some fancy pants replication, security or auditing stuff I'll stare at you with a completely blank expression... Our DBAs however eat that stuff for breakfast!
Ben
^ Thats me!
----------------------------------------
01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
----------------------------------------
March 12, 2014 at 9:00 am
My point exactly. In an enterprise our size, they are definitely different, not lesser, skill sets. It's funny, I developed to get my CS degree and that's definitely been a big help, but we have mathematicians and statisticians by training who are excellent DBA's.
March 12, 2014 at 9:14 am
rlortega (3/12/2014)
I guess a differentiation must be made in skills required for administration and skills required for development. We have 15 DBA's and twice that many developers. We are DBA's but we do not develop. We tune at the instance and server level but query tuning is done by the developers, with our assistance.Of course, we have hundreds of databases on many servers.
The list is not intended to differentiate between dev and DBA roles. There's a degree of overlap and I've included a few DBA skills which I wouldn't want to live without.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden
November 3, 2017 at 3:52 am
I'm in favour of the "several skill-sets" point of view.
There seems to be a "base set" of understanding and then other sets need to be added on top of that, depending on what someone needs to do. In each set awareness of the others has value. "Knowing what you don't know" or "Knowing your limitations" are useful.
One little thing I would like at a pretty basic level is more awareness of SELECT _DISTINCT_, for both the good things and bad things it can do!
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
November 3, 2017 at 8:00 am
So for us wannabes, what is the best way to learn these basic level T-SQL skills? Obviously a Google search on each one would return a number of resources. I was just curious if there was a single source. Maybe a topic for a future SQL Server Central article? 😀
November 3, 2017 at 8:27 am
andrew.jones 69458 - Friday, November 3, 2017 8:00 AMSo for us wannabes, what is the best way to learn these basic level T-SQL skills? Obviously a Google search on each one would return a number of resources. I was just curious if there was a single source. Maybe a topic for a future SQL Server Central article? 😀
If someone was starting from nowhere, I would suggest working with SELECT on a single table and then, using Steve Jones' list as a starting point,
- (4a) finding duplicate rows (grouping, joins)
- (2) returning aggregates of single or multiple columns (MAX, MIN, SUM, COUNT)
- (3) return aggregates in groups, or islands. (grouping and aggregates, windowing)
- (4b) join multiple tables together on matching, multiple columns (joins)
- (5) find data in one table that doesn't have matches in another (outer joins)
- (1) filtering data (WHERE)
- subqueries and complex CTE joins of data
- create row numbers and join back to a table without numbers (APPLY)
- pivoting data from rows to columns
*) Work through the items in the order I've indicated.
*) After that, I would tell them to take a digression into INSERT, UPDATE and DELETE (so they learn a little about creating data),
*) Then another digression into DDL and create their own tables (and Indexes) (so they learn about the effects of the database design/structure)
The good thing about all of that is that it's almost pure SQL and very portable (SQL Server, Oracle, DB/2 etc).
You're right though. There are plenty of "deep technical references", some good, some less so. There are also plenty of introductions ("SELECT * FROM TableName"), But there are not so many places which take you through a process of learning some of the stuff in Steve's list.
I write courses (on SQL among other things) and I'm still learning. _I'd_ be interested in your "single source" (though it might put me out of a job! 😉 )
Tom Gillies LinkedIn Profilewww.DuhallowGreyGeek.com[/url]
November 3, 2017 at 9:01 am
Glad to see someone mention referential integrity - I have seen some disasters resulting from the growing non-relational trend.
In addition to knowing basic SQL programming I think it is important to know that there are limitations with certain elements (eg CTE's, pivots) and that one should be able to use other means to achieve an outcome (eg pivot task in SSIS, dynamic SQL etc).
MattF
November 4, 2017 at 3:31 am
andrew.jones 69458 - Friday, November 3, 2017 8:00 AMSo for us wannabes, what is the best way to learn these basic level T-SQL skills? Obviously a Google search on each one would return a number of resources. I was just curious if there was a single source. Maybe a topic for a future SQL Server Central article? 😀
No, there isn't a single source - there is far too much knowledge for any single source, and a good bit of it is opinion anyway, not necessarily iron-clad TRUTH. Different people have different ways of doing things, and several ways may be legitimate, or better in some specific circumstance.
But just being here is a good place to start. Look at the 'Stairway' articles on this site, they provide lots of basic info. Then look at the blogs of some of the heavyweights that regularly contribute to this site, like Grant Fritchey and Gail Shaw. They both have many excellent tutorials on their sites.
But you'll have to get your hands dirty - set up a machine with SQL Server, or make an instance on an existing one that will not impact production, and start experimenting. Try things: copy code snippets and dig through them to see how and why they do what they do, make changes and observe the effects, scan the forums to see what other people are asking and replying on a subject. You can learn a great deal by reading a dialog between someone with a problem and a master leading them to the solution.
And if you really get stuck, ask! Check over the posting guidelines, to make sure your question is formulated in a sensible way, instead of vague "Please help!" bleatings, and post what is holding you up. You may even find that the process of having to organize your thoughts in a coherent enough manner to formulate your question will itself cause you to hit upon the answer. It has happened to me more than once.
November 4, 2017 at 5:08 pm
Jeff Moden - Friday, November 29, 2013 10:37 AMThe exception to that rule is that spelling errors are simply not forgivable and incorrect substitution of correctly spelled words (for example, you meant to use the word "data" but used "date" instead) are mostly not forgivable (I'll allow only 1 or 2) because if you don't care that much about your own resume, why would you care about the job at hand?
But what do you count as spelling errors? If you have a resumé (oh heck, do you think that's a spelling error? I would think your "resume" was a spelling error if I didn't know that you are one of those poor souls suffering from the barbarous effects on spelling resulting from Noah Webster's dislike of Jefferson and of republicans generally so that came to reject the spellings used by the founding fathers. Would you treat my spellings like "centre" where you would have "center" as an unforgivable spelling error? If so, you would probably reject anyone who learnt English in any country in Europe or in any Asian or African country where English is widely used or in any of the Australasian countries where English is an (or the) official language. And you'ld probably fail some Canadians too as you prefer "resume" to "resumé".
For me, a spelling error in a resumé usually makes me think the writer chose to use a spell-checker that I don't like, not that they can't be bothered to spell "correctly", because "correctly" is meaningless when there are more than one spelling standards for the language. Of course there are some spelling errors that are beyond the pale ("cnetre" for "centre" is clearly a sign of sloppiness, for example.)
Tom
November 4, 2017 at 5:18 pm
TomThomson - Saturday, November 4, 2017 5:08 PMJeff Moden - Friday, November 29, 2013 10:37 AMThe exception to that rule is that spelling errors are simply not forgivable and incorrect substitution of correctly spelled words (for example, you meant to use the word "data" but used "date" instead) are mostly not forgivable (I'll allow only 1 or 2) because if you don't care that much about your own resume, why would you care about the job at hand?But what do you count as spelling errors? If you have a resumé (oh heck, do you think that's a spelling error? I would think your "resume" was a spelling error if I didn't know that you are one of those poor souls suffering from the barbarous effects on spelling resulting from Noah Webster's dislike of Jefferson and of republicans generally so that came to reject the spellings used by the founding fathers. Would you treat my spellings like "centre" where you would have "center" as an unforgivable spelling error? If so, you would probably reject anyone who learnt English in any country in Europe or in any Asian or African country where English is widely used or in any of the Australasian countries where English is an (or the) official language. And you'ld probably fail some Canadians too as you prefer "resume" to "resumé".
For me, a spelling error in a resumé usually makes me think the writer chose to use a spell-checker that I don't like, not that they can't be bothered to spell "correctly", because "correctly" is meaningless when there are more than one spelling standards for the language. Of course there are some spelling errors that are beyond the pale ("cnetre" for "centre" is clearly a sign of sloppiness, for example.)
No... I do consider the source. What I am talking about are the clear signs of sloppiness that you speak of. The mistyping of "date" when you obviously meant "data" is another. Heh... I've even learned that "learnt" means the same thing and is acceptable. 😉 That was a very early lesson from more than 2 decades ago.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 76 through 90 (of 105 total)
You must be logged in to reply to this topic. Login to reply