From 4b32f047a39c243fa2cba683723a96bdfff5d7a4 Mon Sep 17 00:00:00 2001
From: Ethan <ethanytchang@gmail.com>
Date: Wed, 30 Oct 2024 23:44:35 -0500
Subject: [PATCH] added query analysis

---
 doc/DatabaseDesign.md | 285 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 284 insertions(+), 1 deletion(-)

diff --git a/doc/DatabaseDesign.md b/doc/DatabaseDesign.md
index 6f02239..607f406 100644
--- a/doc/DatabaseDesign.md
+++ b/doc/DatabaseDesign.md
@@ -110,6 +110,64 @@ LIMIT 15;
 ### Example Execution on MySQL DB
 ![alt_text](imgs/query1.png)
 
+### Query Analysis
+**Attributes of GameHistory Table Used in Query \#1 JOIN/GROUP BY/HAVING/WHERE and NOT PRIMARY KEY:**
+
+UserID, balance action\_pre, action\_flop, action\_turn, action\_river
+
+**Index Groupings:**
+
+1. UserID  
+2. balance  
+3. (UserID, balance)  
+4. (UserID, action\_pre) \+ (UserID, action\_flop) \+ (UserID, action\_turn) \+ (UserID, action\_river)  
+5. (UserID, balance, action\_pre) \+ (UserID, balance, action\_flop) \+ (UserID, balance, action\_turn) \+ (UserID, balance, action\_river)
+
+Cost Analysis (Before Using Indexes): 
+
+![query1pre.png](imgs/query1pre.png)
+
+
+**Cost: 84226**
+
+Cost Analysis (Index Grouping 1):
+
+![query1_1.png](imgs/query1_1.png)
+
+**Cost: 84226**
+
+Cost Analysis (Index Grouping 2):
+
+![query1_2.png](imgs/query1_2.png)
+
+**Cost: 84226**
+
+Cost Analysis (Index Grouping 3):
+
+![query1_3.png](imgs/query1_3.png)
+
+**Cost: 84226**
+
+Cost Analysis (Index Grouping 4):
+
+![query1_4.png](imgs/query1_4.png)
+
+
+**Cost: 84226**
+
+Cost Analysis (Index Grouping 5):
+
+![query1_5.png](imgs/query1_5.png)
+
+
+**Cost: 84226**
+
+#### Analysis
+For this query, we notice that all the indexes we explored had no net change on the cost. We notice that running this query without the use of indexes results in a cost of 84226 and this number did not improve throughout testing 5 different index groupings. A reason for this could be due to the fact that our query is structured such that all rows in the GameHistory table have to be processed given that our query does not have a WHERE clause. The need to process all rows in our table can also be due to the fact that we are employing multiple aggregate functions in the query as well.  
+   
+In this case, there is no need to index.
+
+
 ## 2. Currently Playing With
 This query returns the skins of all the players in a specific room. 
 
@@ -121,7 +179,49 @@ JOIN Skin ON SkinID = CurrentSkin
 LIMIT 15;
 ```
 ### Example Execution on MySQL DB
-![alt_text](imgs/query2.png)
+![query2.png](imgs/query2.png)
+
+### Query Analysis
+**Attributes of Account table Used in Query \#2 JOIN/GROUP BY/HAVING/WHERE and NOT PRIMARY KEY:**
+
+RoomID (Account), CurrentSkin (Account)
+
+**Index Groupings:**
+
+1. RoomID (single attribute index)  
+2. CurrentSkin (Account)  
+3. (RoomID,CurrentSkin)
+
+Cost Analysis (Before Adding Indexes): 
+
+![query2pre.png](imgs/query2pre.png)
+
+**Cost: 464**
+
+Cost Analysis (Index Grouping 1):
+
+![query2_1.png](imgs/query2_1.png)
+
+
+**Cost: 464**
+
+Cost Analysis (Index Grouping 2):
+
+![query2_2.png](imgs/query2_2.png)
+
+**Cost: 391**
+
+Cost Analysis (Index Grouping 3):
+
+![query2_3.png](imgs/query2_3.png)
+
+
+**Cost: 464**
+
+#### Analysis
+
+We notice that starting from an initial cost of 464 where the query was run with no indexes and having tested out three indexes, the second one (having an index on the CurrentSkin attribute) reduces the cost while the other two indexes had no effect on cost. Therefore, for our final design, we will choose to add an index on CurrentSkin in the Account table.
+
 
 ## 3. Activity Tracker
 This query retrieves the daily activity of a user over multiple days, specifically counting the total amount of transactions that occur in game and outside of the games every day. 
@@ -149,6 +249,81 @@ ORDER BY g.Date
 LIMIT 15;
 ```
 
+### Query Analysis
+**Attributes of GameHistory/Transactions Used in Query \#3 JOIN/GROUP BY/HAVING/WHERE and NOT PRIMARY KEY:**
+
+UserID (GameHistory), DateTime (GameHistory), DateTime (Transaction), SenderID (Transaction), ReceiverID (Transaction)
+
+**Index Groupings:**
+
+1. UserID (GameHistory), DateTime (GameHistory)  
+2. SenderID (Transaction), DateTime (Transaction)   
+3. ReceiverID (Transaction), DateTime (Transaction)   
+4. SenderID (Transaction), ReceiverID (Transaction), DateTime (Transaction) \=\> grouped on UIDs in transaction  
+5. (UserID (GameHistory), DateTime (GameHistory)) \+ (SenderID (Transaction),DateTime (Transaction))  
+6. (UserID (GameHistory), DateTime (GameHistory)) \+ (ReceiverID (Transaction),DateTime (Transaction))  
+7. (UserID (GameHistory), DateTime (GameHistory)) \+ (SenderID(Transaction),ReceiverID (Transaction),DateTime (Transaction))
+
+Cost Analysis (Before Using Indexes):
+
+![query3pre.png](imgs/query3pre.png)
+
+**Cost: 792433**
+
+
+Cost Analysis (Index Grouping 1):
+
+![query3_1.png](imgs/query3_1.png)
+
+
+**Cost: 440757**
+
+Cost Analysis (Index Grouping 2):
+
+![query3_2.png](imgs/query3_2.png)
+
+**Cost: 221027**
+
+Cost Analysis (Index Grouping 3): 
+
+![query3_3.png](imgs/query3_3.png)
+
+**Cost: 221027**
+
+Cost Analysis (Index Grouping 4):
+
+![query3_4.png](imgs/query3_4.png)
+
+**Cost: 396733**
+
+Cost Analysis (Index Grouping 5):
+
+![query3_5.png](imgs/query3_5.png)
+
+**Cost: 221027**
+
+Cost Analysis (Index Grouping 6):
+
+![query3_6.png](imgs/query3_6.png)
+
+**Cost: 396797**
+
+Cost Analysis (Index Grouping 7):
+
+![query3_7.png](imgs/query3_7.png)
+
+
+**Cost: 221027**
+
+#### Analysis
+
+Our query starts with a significant initial cost of 792433 when run with no selected indices. From this, we test out 7 different index groupings from the following attributes which we narrowed down to have potentially the most significant impact on **reducing cost: UserID (GameHistory), DateTime **(GameHistory), DateTime (Transaction), SenderID (Transaction), and ReceiverID (Transaction). 
+
+We notice that index 2, 3, 5, and 7 all shared the lowest total cost at 221027. An index on the GameHistory table is not required, while it absolutely is required in the Transaction table on attributes DateTime and either SenderID or ReceiverID. In the case that we do add an attribute on UserID and DateTime in the GameHistory table, then we have to also add an attribute on both SenderID and ReceiverID, in addition to DateTime, in the Transaction table.
+
+Therefore, for simplicity sake, we decided to add an index on just the SenderID and DateTime attributes in the Transaction table.
+
+
 ### Example Execution on MySQL DB
 ![alt_text](imgs/query3.png)
 
@@ -167,6 +342,71 @@ LIMIT 15;
 ### Example Execution on MySQL DB
 ![alt_text](imgs/query4.png)
 
+### Query Analysis
+**Attributes of Transaction Used in Query \#4 JOIN/GROUP BY/HAVING/WHERE and NOT PRIMARY KEY:**
+
+DateTime, SenderUID, ReceiverUID, Amount
+
+**Index Groupings:**
+
+1. DateTime (Transaction)  
+2. SenderID  
+3. ReceiverID  
+4. SenderID,ReceiverID \=\> groped on IDs in transaction  
+5. Amount (Transaction) \=\> grouped on amount  
+6. DateTime, SenderUID, ReceiverUID, Amount \=\> grouped by all attributes
+
+Cost Analysis (Before Using Indexes): 
+
+![query4pre.png](imgs/query4pre.png)
+
+**Cost: 8794**
+
+Cost Analysis (Index Grouping 1):
+
+![query4_1.png](imgs/query4_1.png)
+
+**Cost: 8794**
+
+Cost Analysis (Index Grouping 2):
+
+![query4_2.png](imgs/query4_2.png)
+
+**Cost: 8794**
+
+Cost Analysis (Index Grouping 3): 
+
+![query4_3.png](imgs/query4_3.png)
+
+**Cost: 8794**
+
+Cost Analysis (Index Grouping 4): 
+
+![query4_4.png](imgs/query4_4.png)
+
+**Cost: 8794**
+
+Cost Analysis (Index Grouping 5): 
+
+![query4_5.png](imgs/query4_5.png)
+
+**Cost: 8794**
+
+Cost Analysis (Index Grouping 6):
+
+![query4_6.png](imgs/query4_6.png)
+
+**Cost: 8794**
+
+#### Analysis
+
+For this query, we notice that all the indexes we explored had no net change on the cost. We notice that running this query without the use of indexes results in a cost of 8794 and this number did not improve throughout testing 6 different index groupings. 
+
+A potential reason for this could be due to the OR condition in our WHERE clause. While we are filtering rows in the Transaction table, the use of the OR operator ensures that there are still a lot of rows that can be considered, which can lead to a decreased search optimization. 
+
+In this case, there is no need to index.
+
+
 ## 5. Round statistics
 This query retrieves the game histories of all players involved in the game that a specific player was in. The results will be grouped by players to show the individual stats of the players involved in the game. 
 ### SQL Code
@@ -188,3 +428,46 @@ LIMIT 15;
 
 *Note: the output is less than 15 rows. We will be using this query to get stats on every person the arbitrarily selected user* `00021ae5` *played against. When the user* `00021ae5` *plays against more distinct people, this set will increase. We will call this query when we have a specific UserID we want to look at.*
 
+### Query Analysis
+**Attributes of GameHistory Used in Query \#5 JOIN/GROUP BY/HAVING/WHERE and NOT PRIMARY KEY:**
+
+UserID, HandID
+
+**Index Groupings:**
+
+1. UserID  
+2. HandID  
+3. (UserID,HandID)
+
+Cost Analysis (Before Using Indexes): 
+
+![query5pre.png](imgs/query5pre.png)
+
+**Cost: 1.07e9**
+
+Cost Analysis (Index Grouping 1): 
+
+![query5_1.png](imgs/query5_1.png)
+
+**Cost: 55103**
+
+Cost Analysis (Index Grouping 2):
+
+![query5_2.png](imgs/query5_2.png)
+
+**Cost: 81060**
+
+Cost Analysis (Index Grouping 3):
+
+![query5_3.png](imgs/query5_3.png)
+
+**Cost: 46886**
+
+#### Analysis
+
+Our query starts with a significant initial cost of 1.07e9 when run with no selected indices. From this, we test out 3 different index groupings from the following attributes which we narrowed down to have potentially the most significant impact on reducing cost: UserID (GameHistory), HandID (GameHistory) 
+
+
+We notice that of the three indices, adding an index on HandID resulted in the lowest cost decrease from our original starting point (although it improved total cost by a significant margin), followed by indexing UserID, and finally ending with the greatest cost decrease when indexing both HandID and UserID together. 
+
+Due to this, our final index design will be to add an index to both the HandID and UserID attributes in the GameHistory table.