Merge pull request #11 from zdj21jdz/master
Added SQL questions to the ReadME
This commit is contained in:
Arie Bregman
GitHub
commit
12d04e5ba0
186
README.md
186
README.md
@ -3,7 +3,7 @@
|
||||
|
||||
:information_source: This repository contains interview questions on various DevOps related topics
|
||||
|
||||
:bar_chart: There are currently **300** questions
|
||||
:bar_chart: There are currently **312** questions
|
||||
|
||||
:warning: You don't need to know how to answer all the questions in this repo. DevOps is not about knowing all :)
|
||||
|
||||
@ -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,187 @@ 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 * <br>
|
||||
From Customers;
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>How many items are in John's cart?</summary><br><b>
|
||||
|
||||
Select Items_in_cart <br>
|
||||
From Customers <br>
|
||||
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 <br>
|
||||
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 <br>
|
||||
From Customers <br>
|
||||
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>
|
||||
|
||||
<details>
|
||||
<summary>How would you show which customer ordered which items?</summary><br><b>
|
||||
|
||||
Select c.Customer_Name, o.Item <br>
|
||||
From Customers c <br>
|
||||
Left Join Orders o <br>
|
||||
On c.Customer_ID = o.Customer_ID;
|
||||
|
||||
</b></details>
|
||||
|
||||
<a name="sql-advanced"></a>
|
||||
#### Advanced
|
||||
|
||||
<details>
|
||||
<summary>Using a with statement, how would you show who ordered cat food, and the total amount of money spent?</summary><br><b>
|
||||
|
||||
with cat_food as ( <br>
|
||||
Select Customer_ID, SUM(Price) as TOTAL_PRICE <br>
|
||||
From Orders <br>
|
||||
Where Item like "%Cat Food%" <br>
|
||||
Group by Customer_ID <br>
|
||||
) <br>
|
||||
Select Customer_name, TOTAL_PRICE <br>
|
||||
From Customers c <br>
|
||||
Inner JOIN cat_food f <br>
|
||||
ON c.Customer_ID = f.Customer_ID <br>
|
||||
where c.Customer_ID in (Select Customer_ID from cat_food);
|
||||
|
||||
Although this was a simple statement, the "with" clause really shines is when
|
||||
a complex query needs to be run on a table before joining to another. With statements are nice,
|
||||
because you create a pseudo temp when running your query, instead of creating a whole new table.
|
||||
|
||||
The Sum of all the purchases of cat food weren't readily available, so we used a with statement to create
|
||||
the pseudo table to retrieve the sum of the prices spent by each customer, then join the table normally.
|
||||
</b></details>
|
||||
|
||||
## Scenarios
|
||||
|
||||
Scenarios are questions which don't have verbal answer and require you one of the following:
|
||||
|
||||
BIN
images/sql.png
Normal file
BIN
images/sql.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 23 KiB |
Loading…
Reference in New Issue
Block a user