DATABASES & SQL · EXAM · 1:1
Four to five sessions before the exam. We work through the ER model and normalisation, write SQL queries with joins and aggregation, and clear up transactions until ACID is no longer a riddle.
Dennis LIVE Senior Engineer · SQL daily responds ≤ 2 h , View profile Free first chat →
Already decided? Straight to a session →
Live from a databases session
-- Customers with more than 3 orders SELECT c.name, COUNT(*) AS total FROM customer c JOIN orders o ON o.customer_id = c.id GROUP BY c.name HAVING COUNT(*) > 3;
Database exams follow a stable pattern: a modelling block (ER, relational model, normalisation), an SQL block (writing queries) and a theory block (transactions, indexes). We drill each on your past papers.
Pay per session or grab an exam package. The intro call is free: if it is not a fit, you have lost nothing.
No memorised query. We build the SQL query step by step, the way you have to derive it in the exam.
Given the tables customer(id, name) and orders(id, customer_id, amount). Return the names of all customers with more than 3 orders.
SELECT c.name, COUNT(*) AS total FROM customer c JOIN orders o ON o.customer_id = c.id GROUP BY c.id, c.name HAVING COUNT(*) > 3;
The solution is a JOIN with GROUP BY and HAVING COUNT(*) > 3: HAVING filters groups, WHERE would only filter rows.
We need data from both tables, so a JOIN on orders.customer_id = customer.id. That ties each order to its customer.
GROUP BY collapses the rows per customer, COUNT(*) counts the orders per group. All non-aggregated columns go in the GROUP BY.
The condition refers to the result of COUNT, that is to groups. That is what HAVING is for, not WHERE. HAVING COUNT(*) > 3 gives the answer.
Conditions on aggregated values belong in HAVING, conditions on individual rows in WHERE. Mix them up and you get a syntax error or the wrong result.
That is exactly what we practise in your session: writing queries against your own schema, not just reading them.
Start now and invest 4 to 5 sessions and your chances are good. Less time? We compress. More? We go deeper, into query optimisation or concurrency.
You share your screen, we go through your latest exercise and exam scope. We see where you really stand, not where you think you do.
We draw ER diagrams, map them to the relational model and normalise to 3NF, on your actual exam material.
Joins, grouping, subqueries: you write queries against a given schema, I probe until the patterns stick. Plus transactions and indexes.
You solve your university's mock exam against the clock. We review every task: what is solid, where you get stuck and which task types are likely to come up.
I built Study IT because I have seen first-hand how IT teaching at university falls apart.
The people who teach here know code from real projects. Practice decides, not the diploma.
Reach me directly: marcel.schmidtpeter@study-it.education
Senior backend experience with SQL in daily use: ER modelling, normalisation, joins and transactions explained on real schemas, not just textbook examples.
„Programmieren versteht man, wenn man weiß, warum eine Lösung funktioniert. Mein Ziel: dass du Code nicht abschreibst, sondern selbst hinkriegst."
If databases is not your bottleneck, one of these pages probably fits better.
Free intro call, 30 minutes. We look at your material and tell you honestly how many sessions you need.
