Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««56789»»

Core T-SQL Expand / Collapse
Author
Message
Posted Tuesday, December 3, 2013 6:08 AM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Today @ 9:31 AM
Points: 680, Visits: 6,853
ChrisM@Work (12/3/2013)
Steve Jones - SSC Editor (12/2/2013)
L' Eomot Inversé (11/24/2013)
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.


I tend to agree. I was just focusing on T-SQL here. There are other skills, but we can easily get to a large list that's hard to discuss/debate.


I'm also inclined to agree with Tom, however, converting "the bigger picture" into a set of bullet points isn't straightforward. "Know your data", for instance. How you acquire that knowledge, with or without a usable ERD, is driven by numerous factors. Just thinking about it - and I'm in the middle of the process right now, two weeks into a new gig - it seems like a different method every time.


Relationships in the data - they only tell a small part of the story, especially in a data warehouse. Many times there will be a Business Logic layer, and this can be a key part in really 'understanding' the data.
I fall into the same thought pattern as Tom. If it is just the technical skills that they have, it's very possible that they are only a good order taker. The best work is usually the result of good back and forth conversation with the business, especially when a developer can map out some of the what if scenarios.

In light of how quickly the list can grow and vary in different environments, it is hard to focus on just T-SQL.
Desire to learn and master the unknown as it comes up (business changes over time), is something hard to quantify. But I see as important to success, and might be used to cover some of the scope creep.
Post #1519189
Posted Tuesday, March 11, 2014 8:19 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 7:27 AM
Points: 35,770, Visits: 32,437
@ChrisM,

I noticed that you've not written an article on this subject yet and thought I'd give you a nudge. I think the list you came up with is outstanding and I'd love to see it take to the wing in the form of an article. I think you'd do an awesome job at it.


--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1550010
Posted Wednesday, March 12, 2014 2:47 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:43 AM
Points: 6,890, Visits: 14,254
Jeff Moden (3/11/2014)
@ChrisM,

I noticed that you've not written an article on this subject yet and thought I'd give you a nudge. I think the list you came up with is outstanding and I'd love to see it take to the wing in the form of an article. I think you'd do an awesome job at it.


Jeff, I haven't stopped thinking about it since you mentioned it last and I've added a couple of sections since - transactions, ACID and locking and blocking. However, I'm extremely busy both at work and at home and it could be a while before I can tackle it. Here's the thing though - an article of this style is right up your street - Dwain's too, I know you've seen his "Make it Pretty" blog post. If I can't get near it in the next fortnight, it's all yours ol' friend.


“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

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
Exploring Recursive CTEs by Example Dwain Camps
Post #1550076
Posted Wednesday, March 12, 2014 5:44 AM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Today @ 9:31 AM
Points: 680, Visits: 6,853
I see nothing wrong with a 3 author article.
Or at least send it to a couple of others for comments / feedback at this point.
Post #1550163
Posted Wednesday, March 12, 2014 7:30 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:43 AM
Points: 6,890, Visits: 14,254
Neither do I Greg and that’s an excellent point you’ve made.
An article claiming to list the required skill set for a general-purpose TSQL developer, published here on ssc, absolutely has to be first-rate.


“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

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
Exploring Recursive CTEs by Example Dwain Camps
Post #1550228
Posted Wednesday, March 12, 2014 8:03 AM


Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Today @ 9:31 AM
Points: 680, Visits: 6,853
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.
Post #1550248
Posted Wednesday, March 12, 2014 8:13 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 9:37 AM
Points: 5,819, Visits: 3,737
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!!!
Post #1550254
Posted Wednesday, March 12, 2014 8:18 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 1:43 AM
Points: 6,890, Visits: 14,254
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.


“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

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
Exploring Recursive CTEs by Example Dwain Camps
Post #1550257
Posted Wednesday, March 12, 2014 8:25 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Monday, December 15, 2014 3:27 AM
Points: 337, Visits: 2,282
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.
Post #1550263
Posted Wednesday, March 12, 2014 8:49 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, December 12, 2014 8:20 AM
Points: 4, Visits: 24
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.
Post #1550280
« Prev Topic | Next Topic »

Add to briefcase «««56789»»

Permissions Expand / Collapse