diff --git a/leetcode/easy/586-customer-placing-the-largest-number-of-orders/customer-placing-the-largest-number-of-orders.sql b/leetcode/easy/586-customer-placing-the-largest-number-of-orders/customer-placing-the-largest-number-of-orders.sql
index 484453b..2b638cf 100644
--- a/leetcode/easy/586-customer-placing-the-largest-number-of-orders/customer-placing-the-largest-number-of-orders.sql
+++ b/leetcode/easy/586-customer-placing-the-largest-number-of-orders/customer-placing-the-largest-number-of-orders.sql
@@ -9,4 +9,15 @@ LIMIT    1
 
 -- Why are subqueries bad? They're good for readability and often for interviewing. However, in real life subqueries increase the amount of scans taken from the original tables.
 -- From a performance tuning perspective, it's often a good idea to reduce the number of subqueries firing every second on the backend.
--- For interviews, it's often a good idea to go with the subquery.
\ No newline at end of file
+-- For interviews, it's often a good idea to go with the subquery.
+
+WITH RankedCustomers AS (
+    SELECT 
+        customer_number,
+        DENSE_RANK() OVER (ORDER BY COUNT(*) DESC) AS rank
+    FROM Orders
+    GROUP BY customer_number
+)
+SELECT customer_number
+FROM RankedCustomers
+WHERE rank = 1;