In my first post on SQL for I wrote about the SELECT statment . Using shopping in a mall full of shops as a real world reference I mentioned in a mall one has to visit different shops to pick specific items. The act of picking something specific like brown seed loaf from a shelf full of different types of bread equates to the SELECT statement.
The FROM statement does not differ in meaning when used in SQL or when used in conversation. I imagine a shopper reporting back after some shopping at a mall, "I bought some bread FROM the bakery and some sausages FROM the butcher". In a database the shops would be called the tables. Hence the FROM statement is always used to specify from which tables data must be selected.
Different types of professionals need to perform data analysis of some sort. From journalists to doctors doing research. Sooner or later in your data analysis journey you will have to use a database and by extension the Structured Query Language (SQL) used to manage and manipulate data in relational databases.
Like any language SQL has words/terms and each word has a definition and rules about when and how it should be used. I am always at pains to convince none IT people that creators of IT languages go to great lengths to use words that not confusing when designing languages. The first thing I advise new entrants to SQL is to look at the English dictionary meaning of a word to get an idea of how the word should use used in SQL.
SELECT is the first term you will encounter when starting out in SQL. I am a strong believer that if you understand the point of the term, learning to use it is just that much easier. Let me use an analogy for the SELECT key word.
Imagine a database being a mall, a collection of shops in one building. You are sent by your mother to buy a some items armed with a shopping list (because men do not listen or your memory is not as good as you think it is):
- Bread from the baker
- Cake from the baker
- Sausages from the butcher
- Towel from the linen shop
In SQL you should think of the SELECT statement as your shopping list. It has to be precise because for example bakers sell more than just bread. They also sell muffins, cup cakes, Swiss rolls, bagels and so on. You need to pick what you need, in this case bread, from an array of items on the shelf. In the same way when using the SELECT statement in SQL you have to be specific about the columns that you want from the database.
One of the main aims of data visualisations is to represent information or data in a graphical format. A picture can tell the story of a thousand words with a single glance and speak the same language to all people looking at the picture. It is hence always interesting to represent stories with a social and political side in terms of a single graph. In mid 2012 a tragic incident happened in South Africa, 45 people lost their lives during a strike by by miners working for Lonmin mine in Marikana1 2.. The miners were striking for a 22% increase in their wages. 22% is just one of the numbers that tell the story of Marikana. This post collects some of the numbers and represents them in a graph.
There are many opinions on the Marikana tragedy. The unions have blamed the mining company for the manner in which they handled the strike. The workers say the union leaders, particularly those belonging to the National Union of Mineworkers (NUM) have lost touch with the miners.
Social commentators point to the fact that South Africa is one of the highest ranked countries when it comes to the gap between the rich and the poor. It is not for me to say who is right or wrong but perhaps looking at the numbers will give some perspective state of salaries and expenditure surrounding the Marikana tragedy.
It will take a Lonmin rock driller – who earns on average R10 500 in a total-cost-to-company monthly package (working 8 hours a day underground) – almost a decade to earn what the company’s chief executive earns in a month3. The commission established to investigate Marikana will reportedly cost 75 million Rands 4. Its safe to say the lawyers and judges involved will make much more out of Marikana than the miners.
Working in Business Intelligence (BI), I write and execute SQL statements every day. Actually it is more like every other minute. The SQL tool I use is thus very important to me. Over the years I have mainly stuck to SQuirreL SQL Client and wandered off every once in a while to check out different tools. One thing is for sure, no one tool will every have everything you need. At some point in time you have to make a choice based on the features most important to you.
Different database vendors will each have their own frontend specifically developed for their database. Oracle has SQL Developer and Sybase has Interactive SQL and so on. I would advise any budding BI practitioner to probably start with the tool supplied by the vendor. In most cases you will have less compatibility issues and the user can start writing and executing statements from the onset.
For those who use more than one database at a time and want to use the same SQL frontend I would recommend SQuirreL SQL Client or my current favourite tool of choice SQL Workbench\J not MySQL Workbench as these are two totally different products.
Over the next few weeks I will do some blog posts to highlight features I find useful when using SQL Workbench\J and SQuirreL SQL Client. Here are some features technical and not technical that both tools have in common that have led me to use these two tools.
None technical reasons:
- Open Source Software, both are free for commercial use and with the source code available are open to developers to debug or contribute features.
- At the time of writing both are under active development with regular builds being released. Probably about a build (new version) a month apiece. I use the latest testing builds and don't stick to the stable versions. For the faint at heart stick to the stable release versions.
- Active forums, where I was able to get a response to some questions I had on the applications.
- Both applications run on different platforms due to the fact that both are written in Java. This allowed me to use both applications on Windows and Linux
- JDBC as connectivity means it is probably likely that you will be able to connect to any database. Most databases provide a JDBC driver.
- Data explorer component from both products are quite customisable. It is possible to customise the schema's that display, customise the SQL statements generated such as the INSERT, UPDATE or DDL statements created.
- Data import and export wizards for data in various formats including CSV, Microsoft Excel formats XLS and XLSX and OpenOffice formats ODF is possible using both tools. You are likely going to have to experiment here most specifically with date and null fields imports.
- Both tools provide for customisations of how SQL history is handled, frequently used SQL statement, syntax highlighting, connection settings and session customisation to name a few.
Both SQL frontends are very capable and the learning curve for both is pretty steep. This can be expected given the complex nature of working with SQL and working on different databases. Most decent SQL tools have some complexity and instead of learning many different tools I decided to invest time into learning how to effectively use SQL Workbench\J and SQuirreL SQL Client.
I would urge you too to take a serious look at these two tools because you will not get much better generic SQL tools. The alternative which I trailed for a couple of years is using different tools for different databases. For MySQL one could use a tool like HeidiSQL that runs on Windows. For Oracle one could use as TOra which is an OSS frontend primarily focused on Oracle. This would mean learning a different tool for each database once uses. This is okay if you don't change databases often but I find myself using different databases regularly.
Don't be fooled by the dated screen shots on both web pages, these tools look much better. Here are the home pages of the two tools:
Over the next year I will be writing some blog posts with in-depth step by step instructions on how to use some use functions in both tools. Do I have a favourite out of these two, not really. SQuirreL SQL Client is the one I have been using the longest and I really like what I see with SQL Workbench\J.
Just how did the writers of old manage to churn out so much material given that they did not have:
- Word processors,
- the Internet and
- Google for all research?
My take and I am probably not the first person to say this is we may have made technological improvements to make writing much "easier" but along the line we created more things to distract us. For someone working in IT, I have always regarded writing as unimportant and have always done it using a normal word processor such as MS Word or LibreOffice Writer. It never occured to me to use anything else. It was after an extended period of non-productivity I realised the reason I was not writing as much as I would have wanted to was because I was just too easily distracted.
Here is what typically happens, I start writing a piece of documentation, pause to look up a word or term I want to write about and before I know it I am immersed in a WikiPedia article on the history of Linux.
I am trying out two writers for now. I urge you to try them out, you will not turn regret it. After not being able to write a blog post for over a year suddenly I have managed to write two posts in a week and have finished countless work documents. Here are the ones I am trying out:
I have been able to use both applications concurrently without any difficulty. The main feature both provide is a blank screen with just you and your text. They both do have spell checkers and a few more nifty tools like pattern replacement.
Some articles to read with references to other distraction free editors are:
- 20 Fantastic Full Screen Text Editor for Distraction Free Writing
- The Rise Of Distraction-Free Text Editors
Do try out a distraction free editor, all your writing tasks will become much easier.