Tell me about your organisation
Knowing about the customer gives you context to user for the rest of the conversation. There is a different between a multi-million dollar company and a sole proprietor.
What is the purpose of the site
I use this question to gauge the customer expectation of the site. Though I have listed one question, I always add follow up questions based on their answers they give. After this question I now have an idea of the vision the customer has of the site Typical answers for this question include:
- We want to sell more products or acquire more customers
- We want customers to interact with us using our site
- We want people to know who we are and what we do.
- We want people to know where to find us
- We want to sell products online
What functionality would you like to do via your web site
You will need to explain what the functionality means.
- Would you want to update yourself
- How often will you be updating it
- Do you want to have an online shop and process payments online
Do you have sites that you like that we could use as reference
Gives an idea of the users preferences in terms of look and feel. I have found though that users will like very different kinds of sites.
What is your budget?
Some customers are likely not to have this information. This is when I give my breakdown on the costs associated with different types of web sites.
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.