I've mentioned in previous blogs that I was not very good at math in school. I always had to take remedial math. In 8th grade I was in the "Thug Math Class". It was all the kids who had failed out of 8th grade a few times. A lot of those kids were into crime.
A few of them used to actually drive to school! That's how old they were!
In college the situation got better. I wasn't taking classes with criminals, but I was still behind in my math knowledge. I had to take Elementary Algebra at a local community college while at the same time taking my other classes at the local University.
During that Elementary Algebra class "it" clicked! I understood what I was being taught!
FINALLY!
However, it wasn't enough to just understand. I had to practice. I had to do a lot of homework exercises to reinforce what I had learned.
SQL is no different.
If you look at SQL jobs out there...whether they be DBA jobs, BI jobs, MySQL type jobs, PostgreSQL type jobs, Oracle jobs, or SQL Server jobs they all have one thing in common: SQL.
It's irritating going on the job hunt looking for SQL Server jobs. Let's say you don't see many, but you do see a lot of other SQL type jobs. So you set out to learn MySQL, or PostgreSQL, or even Oracle. You land an interview and don't get the position.
Then you get a call that there's a PostgreSQL job. So now you learn PostgreSQL.
You don't know what to focus on!
Here's what helped me: Focus on SQL.
A buddy of mine from work, who has been a senior level SQL DBA for years, told me that "SQL was SQL".
We had been told by upper management that we were switching from SQL Server to PostgreSQL. We were keeping our e-learning platform on MySQL. However, our bread and butter work was going to focus on PostgreSQL instead of SQL Server.
I was starting to panic! I considered myself to be at the junior level of SQL. I felt a lot of anxiety as I thought that there might be a huge learning curve if I had to switch gears from one platform to another.
My friend Rob assured me that, "SQL was SQL." He said that as long as you understood SQL you just had to remember the particular nuisances of each platform. 'Those", he said, "you can just Google."
He was right.
A few blog posts ago I put some links that helped me quite a bit with SQL. Here's another source of help. I've been playing around with this app on my Android phone. It makes practicing SQL pretty fun.
The app is called, "Knowledify SQL".
I've played around with a few SQL practicing apps. I found them to be limited to basic queries. Others didn't allow you to practice queries. They just had basic tutorials.
This app treats SQL like a game. You even get points towards achievements.
I would strongly suggest getting an app like this one. You need to practice SQL quite a bit to get good at it. You also need the repeated practice to get SQL in your head. What I mean is, you need to not only understand it but memorize it. That's where speed develops. Understanding AND memorization.
What's also cool about this app is that you don't need your computer. You don't need to install any particular flavor of SQL.
Imagine, you're sitting there waiting for your doctor to see you. Or your sitting in the car waiting for you kid to get out of school. Instead of just wasting that time you can do something beneficial. You can practice SQL!
I've found that my goal of practicing SQL at least one hour a day in addition to what I do at work is very easy to meet. The other night I spent 3 hours on the app, and didn't even realize it!
Saturday, July 9, 2016
Thursday, July 7, 2016
My First SQL Job Part 4: Summing It Up
Thanks for reading my posts. I hope they will help you on your SQL Career Journey. I'm going to summarize some of my key points in this post.
1. Document and UNDERSTAND everything about the SQL Servers you are responsible for. When I say "SQL Servers" I also mean MySQL, PostgreSQL, and any other RDMS. In my last position we had a mix of Windows SQL Servers, MySQL Servers, and PostgreSQL as well. This isn't actually uncommon as some business are looking to move from one platform to the other.
2. Get a list of tasks and their priorities from your manager. Make sure that your time is being accounted for working towards the goals he or she sets. Your manager has a lot on his mind so make sure you take some time to reiterate what your working on. Your manager's priorities may have changed according to business needs, and you need to stay "in the loop."
3. Make a journal/notebook of your tasks, your progress on them, their due dates, and what you've learned. (This also serves to help you in future interviews by refreshing what you've learned, and being able to clearly tell the interviewer what experiences you have had).
4. Recap what you've been asked to do. I usually do this verbally AND via email. I found that some managers may forget what they told you. When done via email it's almost like a contract that both parties agree to.
5. Make a testing type environment. Practice querying in that environment. Familiarize yourself with the database by performing these queries.
6. Look through database documentation such as the ERD and the Data Dictionary. If these aren't available then you have to create them.
7. Use SQL Server Profiler or the MySQL equivalent. This is helpful when you have no idea how to structure your query, or just want to see how the application developers wrote the query.
1. Document and UNDERSTAND everything about the SQL Servers you are responsible for. When I say "SQL Servers" I also mean MySQL, PostgreSQL, and any other RDMS. In my last position we had a mix of Windows SQL Servers, MySQL Servers, and PostgreSQL as well. This isn't actually uncommon as some business are looking to move from one platform to the other.
2. Get a list of tasks and their priorities from your manager. Make sure that your time is being accounted for working towards the goals he or she sets. Your manager has a lot on his mind so make sure you take some time to reiterate what your working on. Your manager's priorities may have changed according to business needs, and you need to stay "in the loop."
3. Make a journal/notebook of your tasks, your progress on them, their due dates, and what you've learned. (This also serves to help you in future interviews by refreshing what you've learned, and being able to clearly tell the interviewer what experiences you have had).
4. Recap what you've been asked to do. I usually do this verbally AND via email. I found that some managers may forget what they told you. When done via email it's almost like a contract that both parties agree to.
5. Make a testing type environment. Practice querying in that environment. Familiarize yourself with the database by performing these queries.
6. Look through database documentation such as the ERD and the Data Dictionary. If these aren't available then you have to create them.
7. Use SQL Server Profiler or the MySQL equivalent. This is helpful when you have no idea how to structure your query, or just want to see how the application developers wrote the query.
Tuesday, July 5, 2016
My First SQL Job Part 3: Chaos to Understanding
As I mentioned in my previous posts....this was my first actual SQL job. I had been responsible for a SQL Server at my previous job. I had also been tasked with creating a database for a specific department. However, those SQL tasks were in addition to my other responsibilities.
My only responsibility at my first SQL job was....SQL.
This was the job that showed me what a full time DBA actually does. It was a stressful yet exciting time. In a very short amount of time I was exposed to enough SQL equivalent to a year's worth of experience.
As I mentioned in Part 2 of this post, my notebook was invaluable to me. In that notebook I had my tasks, the due dates, the progress I had made, and what I had actually learned. One of my tasks, in fact, my most important task was documentation.
The previous SQL DBA had left with all the documentation he had amassed in the four years he had worked there. So I had to take specific steps. My first step was to find out what servers were the actual SQL Servers I would be working with. My next step was to gather all the relevant information about the servers. I needed their IP addresses, their physical specifications such as RAM and hard drive space.
I also needed to know the version of SQL Server we were running, the size of the database, and the backups.....where were they being placed? On what schedule?
Also...what SSIS packages did what? In my case, what steps had the previous DBA taken when troubleshooting one particular error that kept coming up?
My manager wanted me to use OneNote for documentation purposes. I was a bit opposed to this idea at first because I had very little OneNote experience. I was also used to the old school way of creating a Word Doc or an Excel Spreadsheet for documentation. However, OneNote was great. In fact, I still use it to document the work I do in MySQL when I have side projects.
I had several different notebooks within OneNote. One notebook was about the servers. It had tabs such as Memory, SQL Version, Login Information, Notes, etc. Another notebook was called SSIS Packages. It had screenshots of the packages. It had the SQL code written out and explained. Indeed, it had the actual package steps clearly explained.
I also had a Data Integrity Notebook. This notebook contained all the queries I had come up with to confirm that, at least on the CRM database side of things, the records matched what the program was putting out. As a starting point for my queries I used the SQL Server Profiler. I ran some reports via the CRM's web interface, and captured those queries in the Profiler.
I studied how those queries were put together. I did this by finding the tables in the query, and looking up additional details that were in the Data Dictionary provided by the CRM software's vendor. I also looked at the ERD quite a bit.
I made a copy of the current live database, and put it on another SQL Server. I did this so that my queries wouldn't slow the server down during production hours. The way the database was structured, and the kinds of views my manager wanted, caused timeouts quite often during querying.
Let me give you an example. The CRM had all the companies my company was working with. One of the views I was required to create had all relevant company information: address, phone number, contact person, and financial information. This financial information was actually brought in from the Financial Database via an SSIS package which performed ETL.
Okay, easy enough, right? You know you're going to have to query the company table, right? Wrong. There was no company table. Everything within the database was seen as a contact. Either a company contact or a non-company contact. However, both of these were in one table called, contacts.
There was also a difference between the way the program was meant to be used, and the way the company was using it. There were some built in reports on the web side of the program that if you ran them it would take literally 12 hours to come back with the results. If you performed the same query via SSMS it would time out the database.
I extended the time out period, but this had no effect. I ended up using a trick from my Java programming days. I broke up each view into separate views. So I treated each view as a separate object, or building block, of what I actually wanted. Then I joined all the views together using LEFT and INNER JOINS.
This kept the system from timing out, and gave me the results I needed with very little wait time. I also made it a point to document this particular method. In case sometime later another DBA was trying to figure out why I had done something the way I had done it. After all, this was only a 3 week contractor position.
Was this the correct way of doing things? I didn't know. I was inexperienced and I wasn't getting help with the SQL part of my job. Since I had made a copy of the database I was able to test out my queries without slowing down production.
My numbers came back accurate. That meant my views could be trusted. In fact, I had found that they way the report person was running one of the reports was incorrect. By changing some criteria her report numbers matched exactly what my view had given back.
In IT you often have to think outside of the box. Creating multiple views and JOINing them together was one of those outside of the box moments. I confirmed that each separate view gave me the correct result set in and of itself. I then confirmed that as a whole the new view, which remember was merely the collection of confirmed views JOINed together, gave me the correct result set.
I was fortunate in that I had a Help Desk, and Windows and Linux system administration background. So I was able to use that knowledge to assist me with my tasks.
My only responsibility at my first SQL job was....SQL.
This was the job that showed me what a full time DBA actually does. It was a stressful yet exciting time. In a very short amount of time I was exposed to enough SQL equivalent to a year's worth of experience.
As I mentioned in Part 2 of this post, my notebook was invaluable to me. In that notebook I had my tasks, the due dates, the progress I had made, and what I had actually learned. One of my tasks, in fact, my most important task was documentation.
The previous SQL DBA had left with all the documentation he had amassed in the four years he had worked there. So I had to take specific steps. My first step was to find out what servers were the actual SQL Servers I would be working with. My next step was to gather all the relevant information about the servers. I needed their IP addresses, their physical specifications such as RAM and hard drive space.
I also needed to know the version of SQL Server we were running, the size of the database, and the backups.....where were they being placed? On what schedule?
Also...what SSIS packages did what? In my case, what steps had the previous DBA taken when troubleshooting one particular error that kept coming up?
My manager wanted me to use OneNote for documentation purposes. I was a bit opposed to this idea at first because I had very little OneNote experience. I was also used to the old school way of creating a Word Doc or an Excel Spreadsheet for documentation. However, OneNote was great. In fact, I still use it to document the work I do in MySQL when I have side projects.
I had several different notebooks within OneNote. One notebook was about the servers. It had tabs such as Memory, SQL Version, Login Information, Notes, etc. Another notebook was called SSIS Packages. It had screenshots of the packages. It had the SQL code written out and explained. Indeed, it had the actual package steps clearly explained.
I also had a Data Integrity Notebook. This notebook contained all the queries I had come up with to confirm that, at least on the CRM database side of things, the records matched what the program was putting out. As a starting point for my queries I used the SQL Server Profiler. I ran some reports via the CRM's web interface, and captured those queries in the Profiler.
I studied how those queries were put together. I did this by finding the tables in the query, and looking up additional details that were in the Data Dictionary provided by the CRM software's vendor. I also looked at the ERD quite a bit.
I made a copy of the current live database, and put it on another SQL Server. I did this so that my queries wouldn't slow the server down during production hours. The way the database was structured, and the kinds of views my manager wanted, caused timeouts quite often during querying.
Let me give you an example. The CRM had all the companies my company was working with. One of the views I was required to create had all relevant company information: address, phone number, contact person, and financial information. This financial information was actually brought in from the Financial Database via an SSIS package which performed ETL.
Okay, easy enough, right? You know you're going to have to query the company table, right? Wrong. There was no company table. Everything within the database was seen as a contact. Either a company contact or a non-company contact. However, both of these were in one table called, contacts.
There was also a difference between the way the program was meant to be used, and the way the company was using it. There were some built in reports on the web side of the program that if you ran them it would take literally 12 hours to come back with the results. If you performed the same query via SSMS it would time out the database.
I extended the time out period, but this had no effect. I ended up using a trick from my Java programming days. I broke up each view into separate views. So I treated each view as a separate object, or building block, of what I actually wanted. Then I joined all the views together using LEFT and INNER JOINS.
This kept the system from timing out, and gave me the results I needed with very little wait time. I also made it a point to document this particular method. In case sometime later another DBA was trying to figure out why I had done something the way I had done it. After all, this was only a 3 week contractor position.
Was this the correct way of doing things? I didn't know. I was inexperienced and I wasn't getting help with the SQL part of my job. Since I had made a copy of the database I was able to test out my queries without slowing down production.
My numbers came back accurate. That meant my views could be trusted. In fact, I had found that they way the report person was running one of the reports was incorrect. By changing some criteria her report numbers matched exactly what my view had given back.
In IT you often have to think outside of the box. Creating multiple views and JOINing them together was one of those outside of the box moments. I confirmed that each separate view gave me the correct result set in and of itself. I then confirmed that as a whole the new view, which remember was merely the collection of confirmed views JOINed together, gave me the correct result set.
I was fortunate in that I had a Help Desk, and Windows and Linux system administration background. So I was able to use that knowledge to assist me with my tasks.
My First SQL Job Part 2: Making Sense Out of Chaos
I was way in over my head. That was the bottom line.
My manager had assured me he knew I wasn't very experienced. He assured me that he would teach me what I needed to know for the tasks which lay before me. He also gave me some additional information: He had never done an integration project of this scope and magnitude before. He didn't know what direction to take.
A week into the project my manager told me he didn't have time to teach me. I would have to learn what I needed to know on my own. This caused me a lot of anxiety because I didn't know where to start.
He had told me that he wanted certain views created within SQL to confirm the integrity of the reports that another employee had been running. However, his focus changed quite often. I would find myself on the cusp of completing one of his assignments when he would tell me to stop, and work on another assignment.
I tried to get him to hammer down the priorities he had for me. However, after repeated attempts to get what was important to him conveyed to me I eventually gave up. His priorities changed often, and he didn't know which ones were or weren't important at any given time.
He was under stress from upper management to show progress towards the merger of these two, separate databases, onto Salesforce. He also needed a database created for a department within the company which did salary surveys. Prior to standardizing on SQL this department had used MS Access. After years of use their database was quite large. Many queries were taking literally days to complete!
My anxiety levels went through the roof when he would ask me if I had completed the tasks he had assigned me. I was all over the place. I lacked focus because he didn't particularly give me direction. He also didn't teach me much so I had to learn as I went. So there was this huge learning curve that was just up to me and Google to get over.
I remember that during this time I reached out to my SQL Instructor. I had taken a SQL class for 6 weeks a few months earlier. It focused mostly on certifying for the MCSA in SQL.
I emailed my instructor and briefly explained to him my situation. He told me that what I was describing was Sr. Level work in SQL. He asked what my progress was, and he was shocked at what I had accomplished. He said that I should be proud of myself. (My anxiety had led to feelings of inadequacy. My manager expected high level work from me. I felt that I couldn't deliver to those expectations. My instructor's affirmation helped me a great deal).
Here's something my manager did teach me which was immensely helpful. He had a notebook which had dates, tasks assigned, and the progress made on each task. I had copied what he had for my own notebook format. This was my template of sorts.
I strongly advise anyone in any profession to keep a notebook such as this one. It serves as a journal of sorts. When a manager has asked me what I've accomplished on a particular day, or for a particular week, I can give him facts. I don't have to try and remember what I accomplished a week ago, or two weeks ago. I have it instantly available.
My journal was setup in this way. I'll use a sample entry to show you:
7/5/2016 (Monday)
Had morning meeting with <manager>. We discussed connectors for the SQL Server which would allow us to send data to Salesforce. We need to find a cost effective connector, and test it out thoroughly. I'm to create a very basic SSIS package. The package should be able to convert from an abbreviated state such as 'FL' to the spelled out state. This data should then be written to Salesforce. This is something <manager> wants completed by the end of the business week.
Tasks:
1. Find and test Salesforce connector (Due End of Business Week)
2. Continue work on views
3. Continue documenting SSIS packages in One Note.
As I worked on each task I would jot down my progress, and anything I had learned. As I finished each task I would put a red line through it. I tried to put as much detail in each entry as I could. I also made it a habit to repeat back whatever my manager discussed with me to make sure we were on the same page. I would often follow up with an email for further clarification.
A year later at another job our entire database department was being grilled by a top executive. He didn't feel that we were making much progress with a new online backup system we were testing. Unfortunately, this was due to the fact that the software had some quirks to it. The technical support department for the software had long turnaround times for their support issues. So oftentimes we would have to halt our work until this outside vendor had a solution to our particular issue that week.
In any case, the top executive asked us in frustration, "Just what have you people done this week?" You could see the looks on each face as they tried to remember what they had or hadn't done that week. I opened up my notebook and asked, "Would you like a summary of the week, or would you like to see what tasks were completed on each particular day?"
I said this without disrespect. I've long felt that employers have a right to know just exactly what they're paying you for. This is especially true as a contractor. Some jobs have quantifiable systems. Take a help desk job, for example. You use ticketing software such as Spiceworks. Within that program is quantifiable proof of what you've accomplished.
Not every job is like that. As a database person you don't work within a ticketing system. It depends on your database role. You do have particular tasks that you have to get done, or are working on at the moment. But that information must be conveyed to management. If management doesn't exactly know what you do because they aren't computer people, then you have to have some definite answer for them.
And for non-computer folks you have to have an answer they can understand. They also need to know the importance of the tasks in the context of what the company's particular goals are. The top executive I'm discussing had tasks for us based on what particular goals the company had. It was up to us to "express" these tasks at the SQL level.
I was later told after that meeting with the top executive that I had saved the jobs of the other database staff. By responding with quizzical faces to the question the executive had asked it made it seem that not much was getting done. My response had given him what had been accomplished, what had yet to be accomplished, and why a particular task hadn't been accomplished yet.
My manager had assured me he knew I wasn't very experienced. He assured me that he would teach me what I needed to know for the tasks which lay before me. He also gave me some additional information: He had never done an integration project of this scope and magnitude before. He didn't know what direction to take.
A week into the project my manager told me he didn't have time to teach me. I would have to learn what I needed to know on my own. This caused me a lot of anxiety because I didn't know where to start.
He had told me that he wanted certain views created within SQL to confirm the integrity of the reports that another employee had been running. However, his focus changed quite often. I would find myself on the cusp of completing one of his assignments when he would tell me to stop, and work on another assignment.
I tried to get him to hammer down the priorities he had for me. However, after repeated attempts to get what was important to him conveyed to me I eventually gave up. His priorities changed often, and he didn't know which ones were or weren't important at any given time.
He was under stress from upper management to show progress towards the merger of these two, separate databases, onto Salesforce. He also needed a database created for a department within the company which did salary surveys. Prior to standardizing on SQL this department had used MS Access. After years of use their database was quite large. Many queries were taking literally days to complete!
My anxiety levels went through the roof when he would ask me if I had completed the tasks he had assigned me. I was all over the place. I lacked focus because he didn't particularly give me direction. He also didn't teach me much so I had to learn as I went. So there was this huge learning curve that was just up to me and Google to get over.
I remember that during this time I reached out to my SQL Instructor. I had taken a SQL class for 6 weeks a few months earlier. It focused mostly on certifying for the MCSA in SQL.
I emailed my instructor and briefly explained to him my situation. He told me that what I was describing was Sr. Level work in SQL. He asked what my progress was, and he was shocked at what I had accomplished. He said that I should be proud of myself. (My anxiety had led to feelings of inadequacy. My manager expected high level work from me. I felt that I couldn't deliver to those expectations. My instructor's affirmation helped me a great deal).
Here's something my manager did teach me which was immensely helpful. He had a notebook which had dates, tasks assigned, and the progress made on each task. I had copied what he had for my own notebook format. This was my template of sorts.
I strongly advise anyone in any profession to keep a notebook such as this one. It serves as a journal of sorts. When a manager has asked me what I've accomplished on a particular day, or for a particular week, I can give him facts. I don't have to try and remember what I accomplished a week ago, or two weeks ago. I have it instantly available.
My journal was setup in this way. I'll use a sample entry to show you:
7/5/2016 (Monday)
Had morning meeting with <manager>. We discussed connectors for the SQL Server which would allow us to send data to Salesforce. We need to find a cost effective connector, and test it out thoroughly. I'm to create a very basic SSIS package. The package should be able to convert from an abbreviated state such as 'FL' to the spelled out state. This data should then be written to Salesforce. This is something <manager> wants completed by the end of the business week.
Tasks:
1. Find and test Salesforce connector (Due End of Business Week)
2. Continue work on views
3. Continue documenting SSIS packages in One Note.
As I worked on each task I would jot down my progress, and anything I had learned. As I finished each task I would put a red line through it. I tried to put as much detail in each entry as I could. I also made it a habit to repeat back whatever my manager discussed with me to make sure we were on the same page. I would often follow up with an email for further clarification.
A year later at another job our entire database department was being grilled by a top executive. He didn't feel that we were making much progress with a new online backup system we were testing. Unfortunately, this was due to the fact that the software had some quirks to it. The technical support department for the software had long turnaround times for their support issues. So oftentimes we would have to halt our work until this outside vendor had a solution to our particular issue that week.
In any case, the top executive asked us in frustration, "Just what have you people done this week?" You could see the looks on each face as they tried to remember what they had or hadn't done that week. I opened up my notebook and asked, "Would you like a summary of the week, or would you like to see what tasks were completed on each particular day?"
I said this without disrespect. I've long felt that employers have a right to know just exactly what they're paying you for. This is especially true as a contractor. Some jobs have quantifiable systems. Take a help desk job, for example. You use ticketing software such as Spiceworks. Within that program is quantifiable proof of what you've accomplished.
Not every job is like that. As a database person you don't work within a ticketing system. It depends on your database role. You do have particular tasks that you have to get done, or are working on at the moment. But that information must be conveyed to management. If management doesn't exactly know what you do because they aren't computer people, then you have to have some definite answer for them.
And for non-computer folks you have to have an answer they can understand. They also need to know the importance of the tasks in the context of what the company's particular goals are. The top executive I'm discussing had tasks for us based on what particular goals the company had. It was up to us to "express" these tasks at the SQL level.
I was later told after that meeting with the top executive that I had saved the jobs of the other database staff. By responding with quizzical faces to the question the executive had asked it made it seem that not much was getting done. My response had given him what had been accomplished, what had yet to be accomplished, and why a particular task hadn't been accomplished yet.
Saturday, July 2, 2016
Sites and Videos Which Helped Me With SQL
Back in high school I hated math. Which was no problem since it hated me as well!
I made it into college on the strength of my verbal score on the SAT. My major was originally pre-med biology. Which meant that math would be a part of my everyday life. I either had to like it, and learn it well, or I wouldn't graduate.
I had to take an Intermediate Algebra course in order to be allowed into college. I studied for hours upon hours. In fact, one weekend my favorite singer from my favorite band was giving a concert. David Lee Roth from Van Halen would be a few miles away from me belting out the VH classics!
Alas, I had an algebra exam on that following Monday. Since I was so committed to my college career I skipped out on David's concert. I studied all day and night on both days of the weekend. What did it get me? A 57% on my algebra exam!
I ended up failing that class. (My university didn't kick me out though. They really were wowed by my verbal SAT!)
The instructor told me that I had to swallow my pride, and take an even lower level algebra class. He said I wasn't grasping the basics.
So....I took the lower algebra class. It was basically an introduction to algebra which any 9th grader could've pulled off. However, since I didn't pay attention to much of anything in the 9th grade I figured that now I had hope. Because this time around the old high school algebra circle I was going to FOCUS!
I passed that class with an 'A'. I retook Intermediate Algebra and got an 'A'. I took College Algebra and got an 'A'. I took Calculus I and II and got......yes, you guessed it...an 'A' in both classes.
I discovered that I was really good at mathematics. But it took swallowing my pride, and absorbing the basics at a level meant for a moron. By moron I don't mean a stupid person. I mean a person that just needs an explanation as simple as possible in order to understand.
I've found throughout the years that we techy folks like to impress people with overly complicated explanations. When I'm learning some new technology I HATE the overly techy talk. I want the common sense explanations. I don't care how smart you are, or how smart you think you are. Give me the basics. Don't tell me that, "The rock succumbed to the gravitational forces which surround and permeate the earth."
Just tell me, "The rock fell."
So it's with my seal of approval that I recommend the following websites/videos. ESPECIALLY the video by Derek Banas: https://www.youtube.com/watch?v=yPu6qV5byu4
For practice with explanations from basic querying to advanced querying try:
http://sql-ex.ru/
For every question you could possible have...even ones that expose your outright stupidity (yes, I mean me) try:
http://forums.mysql.com/
I made it into college on the strength of my verbal score on the SAT. My major was originally pre-med biology. Which meant that math would be a part of my everyday life. I either had to like it, and learn it well, or I wouldn't graduate.
I had to take an Intermediate Algebra course in order to be allowed into college. I studied for hours upon hours. In fact, one weekend my favorite singer from my favorite band was giving a concert. David Lee Roth from Van Halen would be a few miles away from me belting out the VH classics!
Alas, I had an algebra exam on that following Monday. Since I was so committed to my college career I skipped out on David's concert. I studied all day and night on both days of the weekend. What did it get me? A 57% on my algebra exam!
I ended up failing that class. (My university didn't kick me out though. They really were wowed by my verbal SAT!)
The instructor told me that I had to swallow my pride, and take an even lower level algebra class. He said I wasn't grasping the basics.
So....I took the lower algebra class. It was basically an introduction to algebra which any 9th grader could've pulled off. However, since I didn't pay attention to much of anything in the 9th grade I figured that now I had hope. Because this time around the old high school algebra circle I was going to FOCUS!
I passed that class with an 'A'. I retook Intermediate Algebra and got an 'A'. I took College Algebra and got an 'A'. I took Calculus I and II and got......yes, you guessed it...an 'A' in both classes.
I discovered that I was really good at mathematics. But it took swallowing my pride, and absorbing the basics at a level meant for a moron. By moron I don't mean a stupid person. I mean a person that just needs an explanation as simple as possible in order to understand.
I've found throughout the years that we techy folks like to impress people with overly complicated explanations. When I'm learning some new technology I HATE the overly techy talk. I want the common sense explanations. I don't care how smart you are, or how smart you think you are. Give me the basics. Don't tell me that, "The rock succumbed to the gravitational forces which surround and permeate the earth."
Just tell me, "The rock fell."
So it's with my seal of approval that I recommend the following websites/videos. ESPECIALLY the video by Derek Banas: https://www.youtube.com/watch?v=yPu6qV5byu4
For practice with explanations from basic querying to advanced querying try:
http://sql-ex.ru/
For every question you could possible have...even ones that expose your outright stupidity (yes, I mean me) try:
http://forums.mysql.com/
My First SQL Job Part 1: Head for the Hills!
I had been exposed to SQL in one way or another for years. I really caught the SQL bug where I worked doing Help Desk, SharePoint, and some System Administration. I had the bug so bad that I made it my goal to get an actual, bonafide SQL job.
I moved to North Carolina and got an interview for a purely SQL type job.
Up to this point I had been exposed ever so slightly to SQL, and had also taken a class on it at a local tech school. I learned a lot in that class, but I found that my instructor's real world knowledge helped me get a more realistic view into the world of SQL.
During my interview I represented myself exactly for what I was: A SQL Newbie.
The Data CEO liked my honesty, and my desire to learn. He also liked that I had a SharePoint background as he wanted to adopt SharePoint into the organization. He, like me, had been a contractor for this particular company and eventually got hired by them.
He laid out the facts for me. He needed a SQL DBA for a 3 week integration project. The previous DBA who had been there four years abruptly left. He also took all the company documentation for their 2 MS SQL servers with him. So task 1 for me was to document everything about those two servers....especially the SSIS jobs that had been setup to run ETL from the CRM Server to the Financial Server.
Suffice it to say.....I was scared.
My first instinct was to head for the hills!!!
So what did I end up doing?
Hmm.....
I moved to North Carolina and got an interview for a purely SQL type job.
Up to this point I had been exposed ever so slightly to SQL, and had also taken a class on it at a local tech school. I learned a lot in that class, but I found that my instructor's real world knowledge helped me get a more realistic view into the world of SQL.
During my interview I represented myself exactly for what I was: A SQL Newbie.
The Data CEO liked my honesty, and my desire to learn. He also liked that I had a SharePoint background as he wanted to adopt SharePoint into the organization. He, like me, had been a contractor for this particular company and eventually got hired by them.
He laid out the facts for me. He needed a SQL DBA for a 3 week integration project. The previous DBA who had been there four years abruptly left. He also took all the company documentation for their 2 MS SQL servers with him. So task 1 for me was to document everything about those two servers....especially the SSIS jobs that had been setup to run ETL from the CRM Server to the Financial Server.
Suffice it to say.....I was scared.
My first instinct was to head for the hills!!!
So what did I end up doing?
Hmm.....
Subscribe to:
Comments (Atom)