Best way to learn SQL from scratch?

tom_e said:
There aren't any that I'm aware of, SQL is one of those things you go on a week long course for at most and then learn on the job.
Click to expand...
Hmm.. What would my best approach be if i wanted to get to an sql interview? I have a more skilled IT role, fine with data (the output of queries), but all vacancies require a couple of years on the job experience
 
morbid42 said:
Hmm.. What would my best approach be if i wanted to get to an sql interview? I have a more skilled IT role, fine with data (the output of queries), but all vacancies require a couple of years on the job experience
Click to expand...

Unfortunately if they specify on the job experience then even a recognised qualification probably won't really help as you'll still be lost in the first paper sift.

Can you not try and work it into your current role if you're already working with data? You can use it in things like Excel.
 
tom_e said:
Unfortunately if they specify on the job experience then even a recognised qualification probably won't really help as you'll still be lost in the first paper sift.

Can you not try and work it into your current role if you're already working with data? You can use it in things like Excel.
Click to expand...

My current role doesnt have access to what i need. Ive some thinking to do
 
The problem I see with not having experience of SQL work history is that you will be quickly found out with theoretically workable SQL answers that can be found in textbooks but are not always applied in the same way in industry. These are the topics below I think you should understand how they are used in industry first :

* left vs right joins (never use right)
* Union all vs Union joins
* views vs stored procs (answers may vary depending on database)
* reusable user defined functions
* ctes vs tables
* understanding query/execution plans
* using variables and choosing the correct data type
* nulls

I suggest that you at least understand the above fundamentals first and how to write scalable sql solutions before attempting to justify the lack of work history. Nearly all the DB jobs I have been to in the past have questions of performance and best practices where the answer is always 'it depends'

Regards,
 
fretted said:
The problem I see with not having experience of SQL work history is that you will be quickly found out with theoretically workable SQL answers that can be found in textbooks but are not always applied in the same way in industry. These are the topics below I think you should understand how they are used in industry first :

* left vs right joins (never use right)
* Union all vs Union joins
* views vs stored procs (answers may vary depending on database)
* reusable user defined functions
* ctes vs tables
* understanding query/execution plans
* using variables and choosing the correct data type
* nulls

I suggest that you at least understand the above fundamentals first and how to write scalable sql solutions before attempting to justify the lack of work history. Nearly all the DB jobs I have been to in the past have questions of performance and best practices where the answer is always 'it depends'

Regards,
Click to expand...
Thanks for the above information, very useful keywords for me to look into.

I do agree that theory and industry are very rarely synced, for any field
 
morbid42 said:
Thanks for the above information, very useful keywords for me to look into.

I do agree that theory and industry are very rarely synced, for any field
Click to expand...

I'd also add learning the differences between oltp and olap databases, when they used in industry and why, and make sure you focus on the right type for the type of jobs you are looking for, and start to spread your learnings once you do.
 
I would suggest following all the advice in this thread but also, you need to know that in production, most databases are NOT in any way perfect. There will be useless data, there will be tables with no keys, no indexes, no thought about relationships with other tables, incorrect data types, etc. You will find horrible code in stored procedures, badly performing queries, parameter sniffing and many other things that could be avoided if people simply followed best practice and took some time to learn and apply their knowledge. Not to put you off but be aware that most businesses use databases heavily yet employ very little effort in maintaining some form of order. Database analysts (in my experience at several companies) are good at running jobs and occasionally suggesting you add an index, but often fall foul of many things themselves. We're only human but we can do better!
 
balanceballs said:
I would suggest following all the advice in this thread but also, you need to know that in production, most databases are NOT in any way perfect. There will be useless data, there will be tables with no keys, no indexes, no thought about relationships with other tables, incorrect data types, etc. You will find horrible code in stored procedures, badly performing queries, parameter sniffing and many other things that could be avoided if people simply followed best practice and took some time to learn and apply their knowledge. Not to put you off but be aware that most businesses use databases heavily yet employ very little effort in maintaining some form of order. Database analysts (in my experience at several companies) are good at running jobs and occasionally suggesting you add an index, but often fall foul of many things themselves. We're only human but we can do better!
Click to expand...

We've just deleted 40 million rows of data from a single table on one of our 60+ clients databases, all useless data :D

We've had issues with long and short date types as well where a job runs at a set time but was missing the first minute of rows that had been entered due to time issues.


Dolph said:
I'd also add learning the differences between oltp and olap databases, when they used in industry and why, and make sure you focus on the right type for the type of jobs you are looking for, and start to spread your learnings once you do.
Click to expand...

2 years in a TSQL based analyst role as that's the first time I've heard those terms.
 
Thanks for this thread. I was looking for resources to learn SQL as I could do with having more skills when job hunting. What is the normal cost for a microsoft certification? Are there any free certificates?
 
noizeuk said:
Thanks for this thread. I was looking for resources to learn SQL as I could do with having more skills when job hunting. What is the normal cost for a microsoft certification? Are there any free certificates?
Click to expand...

Honestly, I work with 30 analysts, none of which have any SQL specific qualifications.

The best thing to do is download some free software such as SSMS, get some sample databases and just start practicing.

You may get an ERD for the database which shows the tables, keys and the relationships between the tables. This will help you when querying multiple tables.

Learn simple selects, joins first. Learn to put things in transactions for anything that makes changes. A transaction makes the change a temp one until you commit it:

BEGIN TRAN

SQL QUERY THAT CHANGES DATA

-- ROLLBACK
-- COMMIT
PRINT @@TRANCOUNT

-- is a comment
rollback will roll back the change you've just made
commit commits the change
the print shows how many open transactions you have open

Personally, we use Transact SQL (TSQL) at work, there's a few different types so worth seeing what's out there.
 
I did a little bit of MYSQL, PHPMYADMIN and PHP pulling and pushing data from websites.

I managed to be able to have a webpage, add data, delete it, and modify it.

that was a little project for myself but never implemented anything live.

I used YouTube tutorials to learn.
 
I've not come across anywhere specifically asking for a certification but a lot of places that ask for experience with SQL will have some sort of test at interview - it's quite easy to get an idea of the candidate's knowledge.
 
You must log in or register to reply here.
Back
Top Bottom