Added SQL questions, as well as SQL Icon for top section of README

README.md

@@ -38,6 +38,9 @@
     <td align="center"><a href="#openshift"><img src="images/openshift.png" width="75px;" height="75px;" alt="OpenShift"/><br /><b>OpenShift</b></a><br /><sub><a href="#openshift-beginner">Beginner :baby:</a></sub><br><sub></td>
     <td align="center"><a href="#shell-scripting"><img src="images/bash.png" width="75px;" height="75px;" alt="Bash"/><br /><b>Shell Scripting</b></a><br /><sub><a href="#shell-scripting-beginner">Beginner :baby:</a></sub><br><sub><a href="#shell-scripting-advanced">Advanced :star:</a></sub></td>
   </tr>
+  <tr>
+    <td align="center"><a href="#sql"><img src="images/sql.png" width="75px;" height="75px;" alt="sql"/><br /><b>SQL</b></a><br /><sub><a href="#sql-beginner">Beginner :baby:</a></sub><br><sub><a href="#sql-advanced">Advanced :star:</a></sub></td>
+  </tr>
 </table>
 </center>
 <!-- markdownlint-enable -->
@@ -2005,6 +2008,160 @@ A short way of using if/else. An example:
 [[ $a = 1 ]] && b="yes, equal" || b="nope"
 </b></details>
 
+## SQL
+
+<a name="sql-beginner"></a>
+#### :baby: Beginner
+
+<details>
+<summary>What does SQL stand for?</summary><br><b>
+
+Structured Query Language
+</b></details>
+
+<details>
+<summary>How is SQL Different from NoSQL</summary><br><b>
+
+The main difference is that SQL databases are structured (data is stored in the form of
+tables with rows and columns - like an excel spreadsheet table) while NoSQL is 
+unstructured, and the data storage can vary depending on how the NoSQL DB is set up, such
+as key-value pair, document-oriented, etc.
+</b></details>
+
+<details>
+<summary>What does it mean when a database is ACID compliant?</summary><br>
+
+ACID stands for Atomicity, Consistency, Isolation, Durability. In order to be ACID compliant, the database much meet each of the four criteria
+
+**Atomicity** - When a change occurs to the database, it should either succeed or fail as a whole. 
+
+For example, if you were to update a table, the update should completely execute. If it only partially executes, the 
+update is considered failed as a whole, and will not go through - the DB will revert back to it's original
+state before the update occurred. It should also be mentioned that Atomicity ensures that each 
+transaction is completed as it's own stand alone "unit" - if any part fails, the whole statement fails.
+
+**Consistency** - any change made to the database should bring it from one valid state into the next.
+
+For example, if you make a change to the DB, it shouldn't corrupt it. Consistency is upheld by checks and constraints that
+are pre-defined in the DB. For example, if you tried to change a value from a string to an int when the column
+should be of datatype string, a consistent DB would not allow this transaction to go through, and the action would
+not be executed
+
+**Isolation** - this ensures that a database will never be seen "mid-update" - as multiple transactions are running at
+the same time, it should still leave the DB in the same state as if the transactions were being run sequentially.
+
+For example, let's say that 20 other people were making changes to the database at the same time. At the
+time you executed your query, 15 of the 20 changes had gone through, but 5 were still in progress. You should
+only see the 15 changes that had completed - you wouldn't see the database mid-update as the change goes through.
+
+**Durability** - Once a change is committed, it will remain committed regardless of what happens
+(power failure, system crash, etc.). This means that all completed transactions 
+must be recorded in non-voliatile memory. 
+
+Note that SQL is by nature ACID compliant. Certain NoSQL DB's can be ACID compliant depending on 
+how they operate, but as a general rule of thumb, NoSQL DB's are not considered ACID compliant
+</details>
+
+<details>
+<summary>When is it best to use SQL? NoSQL?</summary><br><b>
+
+SQL - Best used when data integrity is crucial. SQL is typically implemented with many
+businesses and areas within the finance field due to it's ACID compliance.
+
+NoSQL - Great if you need to scale things quickly. NoSQL was designed with web applications 
+in mind, so it works great if you need to quickly spread the same information around to 
+multiple servers
+
+Additionally, since NoSQL does not adhere to the strict table with columns and rows structure
+that Relational Databases require, you can store different data types together.
+</b></details>
+
+<details>
+<summary>What is a Cartesian Product?</summary><br>
+
+A Cartesian product is when all rows from the first table are joined to all rows in the second
+table. This can be done implicitly by not defining a key to join, or explicitly by 
+calling a CROSS JOIN on two tables, such as below:
+
+Select * from customers **CROSS JOIN** orders;
+
+Note that a Cartesian product can also be a bad thing - when performing a join
+on two tables in which both do not have unique keys, this could cause the returned information
+to be incorrect. 
+</details>
+
+##### SQL Specific Questions
+
+For these questions, we will be using the Customers and Orders tables shown below:
+
+**Customers**
+
+Customer_ID | Customer_Name | Items_in_cart | Cash_spent_to_Date
+------------ | ------------- | ------------- | -------------
+100204 | John Smith | 0 | 20.00
+100205 | Jane Smith | 3 | 40.00
+100206 | Bobby Frank | 1 | 100.20
+
+**ORDERS**
+Customer_ID | Order_ID | Item | Price | Date_sold
+------------ | ------------- | ------------- | ------------- | -------------
+100206 | A123 | Rubber Ducky | 2.20 | 2019-09-18
+100206 | A123 | Bubble Bath | 8.00 | 2019-09-18
+100206 | Q987 | 80-Pack TP | 90.00 | 2019-09-20
+100205 | Z001 | Cat Food - Tuna Fish | 10.00 | 2019-08-05
+100205 | Z001 | Cat Food - Chicken | 10.00 | 2019-08-05
+100205 | Z001 | Cat Food - Beef | 10.00 | 2019-08-05
+100205 | Z001 | Cat Food - Kitty quesadilla | 10.00 | 2019-08-05
+100204 | X202 | Coffee | 20.00 | 2019-04-29
+
+<details>
+<summary>How would I select all fields from this table?</summary><br><b>
+
+Select *
+From Customers;
+</b></details>
+
+<details>
+<summary>How many items are in John's cart?</summary><br><b>
+
+Select Items_in_cart
+From Customers
+Where Customer_Name = "John Smith";
+</b></details>
+
+<details>
+<summary>What is the sum of all the cash spent across all customers?</summary><br><b>
+
+Select SUM(Cash_spent_to_Date) as SUM_CASH
+From Customers;
+</b></details>
+
+<details>
+<summary>How many people have items in their cart?</summary><br><b>
+
+Select count(1) as Number_of_People_w_items
+From Customers
+where Items_in_cart > 0;
+</b></details>
+
+<details>
+<summary>How many people have items in their cart?</summary><br><b>
+
+Select count(1) as Number_of_People_w_items
+From Customers
+where Items_in_cart > 0;
+</b></details>
+
+<details>
+<summary>How would you join the customer table to the order table?</summary><br><b>
+
+You would join them on the unique key. In this case, the unique key is Customer_ID in
+both the Customers table and Orders table
+</b></details>
+
+<a name="sql-advanced"></a>
+#### Advanced
+
 ## Scenarios
 
 Scenarios are questions which don't have verbal answer and require you one of the following: