7 βέλτιστες πρακτικές SQL που πρέπει να ξέρει κάθε developer

Η SQL δεν είναι δύσκολη στο γράψιμο· δύσκολο είναι να τη γράψεις καλά.

Queries που δουλεύουν μια χαρά στο development αρχίζουν να σέρνονται στο production. Ένα ORDER BY που λείπει επιστρέφει ασυνεπή αποτελέσματα, ένα βιαστικό SELECT * σπάει όταν αλλάζει το schema, και φίλτρα που φαίνονται αθώα σε μικρά δεδομένα μπορεί να «κολλήσουν» εντελώς σε μεγάλη κλίμακα.

Με τον καιρό αρχίζεις να βλέπεις μοτίβα που αντέχουν και μοτίβα που δεν αντέχουν.

Οπότε, ορίστε επτά βέλτιστες πρακτικές SQL από την ομάδα πίσω από το Beekeeper Studio, το σύγχρονο, open source, cross-platform GUI για βάσεις δεδομένων.

🔖 Γρήγορη αναφορά: Όσο μαθαίνεις αυτές τις πρακτικές, κράτα πρόχειρο το SQL Language Cheat Sheet μας για γρήγορη αναζήτηση σε SELECT, WHERE, JOIN, aggregates και άλλες βασικές εντολές SQL.

Κατέβασε το Beekeeper Studio

1. Να είσαι συγκεκριμένος — απόφυγε το SELECT *

Το να φέρνεις όλες τις στήλες με SELECT * μοιάζει γρήγορο και ευέλικτο. Δεν χρειάζεται να αποφασίσεις ποιες στήλες θα επιστρέψεις και ποιες θα αφήσεις έξω, και δουλεύει μια χαρά όσο ακόμα εξερευνάς ένα dataset.

Αυτή η ευελιξία όμως έχει κόστος. Καθώς τα schemas εξελίσσονται ή τα joins πολλαπλασιάζονται, το SELECT * μπορεί να φέρει διπλές ή απρόσμενες στήλες, να καθυστερήσει τα queries σου και να δυσκολέψει το debugging.

Επιλέγοντας συγκεκριμένες στήλες, η πρόθεσή σου μένει ξεκάθαρη και ο κώδικάς σου προστατεύεται από σιωπηλά σπασίματα.

-- Risky
SELECT * FROM user_profiles WHERE user_id = 42;

-- Better
SELECT user_id, display_name, avatar_url
FROM user_profiles
WHERE user_id = 42;

2. Χρησιμοποίησε CTE για να απλοποιήσεις σύνθετη λογική

Τα εμφωλευμένα subqueries δουλεύουν, αλλά γρήγορα γίνονται δυσανάγνωστα. Είναι δύσκολο να δεις τι φιλτράρεται πού, και το debugging συνήθως σημαίνει ατελείωτο scroll πάνω-κάτω μέσα σε στρώματα παρενθέσεων.

Τα Common Table Expressions (όροι WITH) σου επιτρέπουν να σπάσεις ένα query σε βήματα με όνομα. Κάθε βήμα μπορεί να εκτελεστεί και να δοκιμαστεί μεμονωμένα, κάνοντας την πρόθεση πιο σαφή και τα λάθη πιο εύκολα στον εντοπισμό. Θυμήσου μόνο ότι κάποιες βάσεις δεδομένων κάνουν materialize τα CTE, οπότε τα inline subqueries μπορεί να είναι πιο γρήγορα σε σφιχτούς βρόχους.

-- Hard to follow
SELECT customer_id, COUNT(*)
FROM (
  SELECT customer_id, created_at
  FROM orders
  WHERE created_at > now() - interval '7 days'
) o
GROUP BY customer_id;

-- Clearer
WITH recent_orders AS (
  SELECT customer_id, created_at
  FROM orders
  WHERE created_at > now() - interval '7 days'
)
SELECT customer_id, COUNT(*)
FROM recent_orders
GROUP BY customer_id;

3. Σχολίαζε την πρόθεσή σου, όχι τη σύνταξη

Τα σχόλια που επαναλαμβάνουν ό,τι ήδη δείχνει η SQL δεν προσθέτουν πολλά. Αυτό που θα ξεχάσεις αργότερα δεν είναι τι κάνει το query, αλλά γιατί υπάρχει.

Μια σύντομη σημείωση για τον σκοπό ή τη χρήση κάνει πιο εύκολο να ξαναπιάσεις ή να παραδώσεις τον κώδικα αργότερα. Γράψε για τον μελλοντικό εαυτό σου ή για τον επόμενο developer που θα προσπαθεί να καταλάβει γιατί μετράει αυτό το query.

-- Find users who signed up but never activated
-- Used in the weekly retention cohort report
SELECT u.id, u.email
FROM users u
LEFT JOIN events e
  ON u.id = e.user_id
  AND e.name = 'account_activated'
WHERE e.id IS NULL
  AND u.created_at > now() - interval '7 days';

4. Κάνε τα φίλτρα σου φιλικά προς τα indexes

Τα indexes βοηθούν μόνο όταν τα φίλτρα σου είναι sargable (συντομογραφία του Search ARGument ABLE). Στην πράξη, αυτό σημαίνει ότι η βάση δεδομένων μπορεί να χρησιμοποιήσει το index απευθείας αντί να σαρώσει κάθε γραμμή.

Αν τυλίξεις μια στήλη σε συνάρτηση — για παράδειγμα LOWER(email) ή DATE(created_at) — ο optimizer δεν μπορεί να χρησιμοποιήσει το index. Ακόμα και οι μετατροπές τύπων μπορεί να έχουν το ίδιο αποτέλεσμα. Το query εξακολουθεί να δουλεύει, αλλά γίνεται πιο αργό όσο μεγαλώνουν τα δεδομένα σου.

-- Not sargable: disables index
WHERE LOWER(email) = 'test@example.com';

-- Sargable: uses existing index
WHERE email = 'test@example.com';

Για να μένουν αποδοτικά τα φίλτρα, γράψ' τα ώστε να ταιριάζουν με τον τρόπο που αποθηκεύονται τα δεδομένα. Αν χρειάζεσαι αναζήτηση χωρίς διάκριση πεζών-κεφαλαίων, αποθήκευσε τις τιμές σε συνεπή μορφή ή πρόσθεσε ένα functional index. Για ημερομηνίες, φίλτραρε με εύρος αντί να μετασχηματίζεις τη στήλη — είναι πιο σαφές και το index παραμένει σε χρήση.

-- Not sargable
WHERE DATE(created_at) = '2025-08-04';

-- Sargable
WHERE created_at >= '2025-08-04'
  AND created_at <  '2025-08-05';

5. Φίλτραρε πριν κάνεις join

Είναι δελεαστικό να κάνεις πρώτα join σε όλα και να φιλτράρεις μετά, ειδικά όταν εξερευνάς ή φτιάχνεις πρωτότυπο. Όμως κάθε join πολλαπλασιάζει τις γραμμές, και κάθε περιττή γραμμή κάνει το query σου πιο αργό και πιο δύσκολο να το σχεδιάσει ο optimizer.

Αντί γι' αυτό, περιόρισε κάθε πίνακα πριν τους συνδυάσεις. Έτσι, η βάση δεδομένων κάνει join μόνο στα δεδομένα που πραγματικά μετράνε — μειώνοντας τη χρήση μνήμης, βελτιώνοντας την αποδοτικότητα της cache και κρατώντας το execution plan προβλέψιμο.

-- Joins every user, even inactive ones
SELECT e.*
FROM users u
JOIN events e ON e.user_id = u.id;

-- Filter first: only active, recently seen users
WITH active_users AS (
  SELECT id
  FROM users
  WHERE active = true
    AND last_seen > now() - interval '90 days'
)
SELECT e.*
FROM active_users u
JOIN events e ON e.user_id = u.id;

6. Προτίμησε το EXISTS αντί για το IN για ελέγχους συσχέτισης

Όταν ελέγχεις αν υπάρχουν σχετικές γραμμές, το IN κάνει τη δουλειά — μέχρι να μην την κάνει. Φτιάχνει μια πλήρη λίστα τιμών, συγκρίνει την καθεμία και χειρίζεται τα NULL με τρόπο που μπορεί να κρύψει έγκυρες αντιστοιχίες.

Το EXISTS δουλεύει διαφορετικά. Επιστρέφει true τη στιγμή που βρίσκει αντιστοιχία και δεν επηρεάζεται από τα NULL στο subquery. Το αποτέλεσμα είναι και πιο γρήγορο και πιο αξιόπιστο, ειδικά σε μεγάλα datasets.

-- Works, but can be slower and NULL-prone
SELECT *
FROM users
WHERE id IN (SELECT user_id FROM orders);

-- Clear and efficient: stops at first match
SELECT *
FROM users u
WHERE EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.user_id = u.id
);

7. Πάντα να ορίζεις ORDER BY

Η SQL δεν εγγυάται τη σειρά των γραμμών, εκτός αν τη ζητήσεις.

Χωρίς ORDER BY, η βάση δεδομένων είναι ελεύθερη να επιστρέψει τις γραμμές με όποια σειρά τη βολεύει, και αυτή μπορεί να αλλάξει από εκτέλεση σε εκτέλεση, από περιβάλλον σε περιβάλλον ή ακόμα και μετά από μικρές ενημερώσεις.

Μπορεί να φαίνεται σταθερό στο development, αλλά μόλις αλλάξουν τα indexes, τα execution plans ή ο όγκος των δεδομένων, θα αρχίσεις να βλέπεις απρόβλεπτο pagination ή ασυνεπή αποτελέσματα στο API.

-- Looks fine until it isn't
SELECT id, name
FROM users
WHERE active = true
LIMIT 10;

-- Predictable and reproducible
SELECT id, name
FROM users
WHERE active = true
ORDER BY created_at DESC
LIMIT 10;

Συνοψίζοντας

Τα καλύτερα queries είναι αυτά που καταλαβαίνεις και έναν χρόνο μετά. Έχουν σαφή πρόθεση, προβλέψιμη συμπεριφορά και καμία κρυφή έκπληξη.

Αυτό είναι το πνεύμα πίσω από αυτές τις συνήθειες. Είναι πρακτικές που χρησιμοποιούμε καθημερινά στο Beekeeper Studio για να κρατάμε τα queries ευανάγνωστα, συνεπή και γρήγορα σε κάθε βάση δεδομένων με την οποία δουλεύουμε.

Μπορείς να κατεβάσεις δωρεάν αυτόν τον οδηγό σε PDF για να τον έχεις πρόχειρο ή να τον μοιραστείς με την ομάδα σου:

Κατέβασε το 7 SQL Habits for Busy Developers

Με το Beekeeper Studio μπορείς να κάνεις αυτές τις συνήθειες καθημερινή πρακτική, με έναν σύγχρονο, cross-platform, open source SQL editor φτιαγμένο για να σε κρατά συγκεντρωμένο.

• Υποστήριξη για 20+ βάσεις δεδομένων: Postgres, MySQL, SQLite, SQL Server, MongoDB, Redis και άλλες.
• Γρήγορος, άμεσος editor: Autocomplete που γνωρίζει το schema, queries σε καρτέλες και syntax highlighting.
• Οπτικά εργαλεία δεδομένων: Περιηγήσου σε πίνακες, επεξεργάσου γραμμές και εξέτασε JSON χωρίς να χάνεις το νήμα.
• AI βοηθός (με προτεραιότητα στο απόρρητο): Το AI εργαλείο κώδικα που έλειπε από τη βάση δεδομένων σου — γνωρίζει το schema, δουλεύει με το LLM της επιλογής σου και σε βοηθά να εξερευνάς και να βελτιώνεις queries πιο γρήγορα.

Κατέβασε το Beekeeper Studio