Λοιπόν, για να ανάψουν λίγο τα αίματα!

 

Ο πόλεμος, κυρίως μεταξύ SQL Server και Oracle, καλά κρατεί. Στο πεδίο της μάχης μπαίνουν κατά καιρούς και υποστηρικτές της DB2 (mainframe for ever!) και φυσικά υπάρχει πάντα το ποσοστό της Sybase, της Informix και άλλων. Εχω παρακολουθήσει ατέλειωτες συζητήσεις όπου κάθε φορά ξεθάβετε το τομαχώκ του πολέμου και ή ένταση αγγίζει τα όρια της εν ψυχρώ ανθρωποκτονίας . Αυτό που μου κάνει κάθε φορά εντύπωση είναι ότι οι υποστηρικτές της μίας πλευράς ελάχιστα έως καθόλου έχουν γνώση των περιορισμών και δυνατοτήτων της άλλης πλευράς και το όλο θέμα περιορίζεται σε καυστικά ειρωνικά σχόλια (μιλάμε για pH = 2) και λεκτικούς διαξιφισμούς, για να μην πω και μία περίπτωση όπου περάσαμε σε πιο πεζές αλλά απείρως πιο πρακτικές μεθόδους επιβολής της γνώμης (εκτόξευση αντικειμένων κλπ).

 

Το να ξεκινήσουμε μία παρόμοια κουβέντα σε forum δε νομίζω ότι έχει νόημα. Στο κάτω κάτω τι να την κάνω την έντονη συζήτηση όταν δεν έχω μπροστά μου τον, εκλεκτό μεν, αλλά ξεροκέφαλο αντίπαλο και δεν μπορώ πχ να του πετάξω το φοριαμό με τα κλασέρ του λογιστηρίου; Προτείνω λοιπόν να πρωτοτυπίσουμε. Οι περισσότεροι από εμάς δουλεύουμε ως επι το πλείστον σε μία από τις RDBMS της αγοράς. Ας ξεκινήσουμε λοιπόν να καταγράφουμε τι ΔΕΝ μας αρέσει στο εργαλείο στο οποίο δουλεύμουμε και τι ΘΑ ΘΕΛΑΜΕ να έχει ή να υλοποιεί διαφορετικά.

 

Και στο τέλος ποιος ξέρει, μπορεί να καταλήξουμε να έχουμε ορίσει τις προδιαγραφές για την τέλεια RDBMS και να τις πουλήσουμε έναντι παχυλότατης αμοιβής

 

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

Τί θα ήθελα να αλλάξει στην Oracle?
1. H εγκατάσταση ΚΑΙ η δημιουργία μιας κενής βάσης να κρατάει λιγότερο από 15 λεπτά. Ναι, μή γελάτε. Με την Oracle 9 μπορεί να πάρει ακόμα και 45 λεπτά. Η Oracle 10 υποτίθεται ότι εγκαθίσταται σε 17 λεπτά, χωρίς όμως τη βάση.
2. Όταν κρεμάνε τα εργαλεία να μου λένε τί συνέβει. Αν πχ. δεν μπορεί να δημιουργηθεί μια βάση γιατί δεν καταλαβαίνει κάποιο setting να μου το λέει αντί να με αφήνει να ψάχνομαι για 1 μέρα να δω τί συμβαίνει (το τί συμβαίνει το περιγράφω παρακάτω).
3. Στοιχειώδης ποιοτικός έλεγχος, κυρίως σε μή αμερικάνικα locales. Δεν έχει πολύ πλάκα να φτιάχνω ένα template βάσης σε ελληνικό Locale, να αποθηκεύει το μέγεθος των αρχείων ως 220,50 MB και μετά να κολλάει γιατί δεν αναγνώρισε το ","! Και να μην δίνει και μήνυμα λάθους. Ή να χάνει το μπούσουλα μόλις ο χρήστης αλλάξει το locale του μηχανήματος.
4. Ομοίως για πίνακες με ελληνικό όνομα. Κάποιος συνάδελφος έγραψε ελληνικούς χαρακτήρες κατά λάθος στο όνομα μιας στήλης. Όλα ωραία και καλά μέχρι που πήγαμε να κάνουμε import τη βάση σε άλλο μηχάνημα. Μπουμ! και ουδεμία εξήγηση!
5. ΕΠΙΤΕΛΟΥΣ! ΑΣ ΦΤΙΑΞΟΥΝ ΤΑ OBJECTS! Δεν είναι δυνατόν ακόμα να υπάρχουν προβλήματα στο πως ορίζεις object types! Ήθελα να δημιουργήσω κάποιους τύπους point, multipoint (πολλά σημεία στη σειρά χωρίς να είναι γραμμή), line (τεθλασμένη γραμμή), polygon. Ωραία και καλά αλλά κάποια select κολλάγανε. Βρήκα τελικά ότι δεν μπορώ να έχω στον ίδιο πίνακα ένα αντικείμενο (π.χ. Point) και ένα collection από αντικείμενα (varray of points για multipoint). Το πρόβλημα αυτό πρέπει να το ανακαλύψανε και να το διορθώσανε το Μάιο. Λογικά με ένα Patch θα λυνόταν το πρόβλημα αλλά
6. Μα είναι δυνατόν τα patches να ζητάνε 170 MB μνήμη για την Java? Και να χρειάζονται και κάτι ωρίτσες να στηθούνε? Έχω να κάνω deploy σε εκατοντάδες μηχανήματα, ποιός θα την κάνει αυτή τη δουλειά? Ο ταμίας του καταστήματος μήπως?
7. Όποιος έγραψε τους SQL generators της Oracle θα πρέπει να καταδικαστεί για εγκλήματα κατά της προγραμματιστικής κοινότητας. Τόσους πολλούς και άχρηστους cursor δεν έχω ξαναδεί. Ένας από τους κύριους λόγους που οι εφαρμογές σε Oracle αργούνε είναι αυτός.
8. Καιρός είναι να παραδεχτεί η Oracle ότι το setup σε Java ήταν μια πολύ κακή ιδέα και να το ξαναγράψει σε Windows Installer. Μπορεί στο Unix ή το Linux να μην υπάρχει κάτι αντίστοιχο, στα Windows όμως μόνο μπελάδες δημιουργεί το setup της Oracle. Και είναι και πολύ αργό. Έχει βγάλει μεν μια "embedded" έκδοση για όσους θέλουν να ενσωματώσουν την Oracle στο setup τους αλλά τί να το κάνω που θέλει μισή ώρα για να τρέξει?
9. Ανθρώπινο documentation. Το documentation της Oracle είναι καλό για εκτύπωση και τελείος ακατάλληλο για online χρήση. Ακόμα να ανακαλύψουνε την έννοια του Hyperlink! Να μην πω και το άλλο ωραίο: Βρίσκεις κάπου μια περιγραφή της μιας παραγράφου που σε στέλνει σε άλλο html αρχείο για πληροφορίες. Εκεί είναι άλλη μια παράγραφος που σε στέλνει πίσω στην αρχή!

Τα τελευταία δύο χρόνια πρέπει να έχω ξοδέψει περισσότερο χρόνο προσπαθώντας να καταλάβω γιατί δεν δουλεύει η Oracle παρά σε άλλες δουλειές. Αν ήθελα τέτοια φασαρία, θα είχα βάλει MySQL, θα πλήρωνα λιγότερα licenses και θα είχα και λιγότερα προβλήματα!

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Ooops, δεν έγραψα εγώ τη γνώμη μου. Λοιπόν θα ήθελα από τον SQL Server:

1. Ανθρώπινο debugger. Αυτός που υπάρχει τώρα για να αρχίσουμε δεν παίζει στο 30% των εγκαταστάσεων για διάφορους σκοτεινούς λόγους. Καν αν πάτε σε google να βρείτε λύση, τότε οι οδηγίες επίλυσης είναι λίγο πιο σύνθετες από το service manual (extended edition) του F-15.

2. Μια διαφορετική υλοποίηση των cursors. ΣΙΓΟΥΡΑ υπάρχει καλύτερος τρόπος, ειδικά στον 2000 που υπάρχει και το table data type.

3. Καλύτερη διαχείρηση των backup devices. Το να μπορώ να προσθέσω ή να τα διαγράψω όλα και προσθέσω δεν είναι διαχείρηση.

4. Error handling. Θεωρώ ότι απλά δεν υπάρχει καθόλου...

5. Να μπορώ να περνάω σαν παράμετρο ένα table data type από SP σε SP. Δεν καταλαβαίνω γιατί δεν γίνεται τη στιγμή που μπορώ να περάσω ένα cursor σαν παράμετρο!

Και κάτι προσωπικό: Να σβήσει κάποιος παρακαλώ τον view designer του Enterprise Manager. Ακόμα μία SP ή view να δώ με κώδικα από τον designer θα γίνω serial killer. Οποιος έφτιαξε τον designer αυτό υλοποίησε στον κώδικα που σημιουργεί τα JOINs ένα ειδικό αλγόριθμο, τον MCW (Most Complicated Way)...

Cursors?
Τί εννοείς διαφορετική υλοποίηση? Ακόμα και στην Oracle οι cursors δεν διαφέρουν ουσιαστικά.

    Όσον αφορά την παράμετρο πίνακα, αυτό έρχεται σε αντίθεση με την ίδια την έννοια του stored procedure. Δεν είναι θέμα του SQL Server αλλά οποιασδήποτε βάσης. Ένα stored procedure μοιάζει με ένα τυπικό procedure, καθώς μπορεί να γράψει κανείς κώδικα. Όταν όμως γίνεται compile το stored procedure αποθηκεύεται και το execution plan των query που περιέχει το stored procedure. Η μορφή του execution plan εξαρτάται από τους πίνακες που χρησιμοποιεί το query, τα indexes που έχουν οριστεί αλλά και τις τιμές που περιέχουν τα indexes. Η χρησιμότητα του stored procedure είναι ότι το execution plan υπάρχει έτοιμο και έτσι δεν χρειάζεται να υπολογίζεται κάθε φορά που καλείται το stored procedure. Το κέρδος για ένα stored procedure που εκτελείται συχνά είναι πολύ σημαντικό.
    Αν τώρα μπορούσες να περάσεις ένα πίνακα σαν παράμετρο, ποιό execution plan θα χρησιμοποιούσε το stored procedure? Το αποθηκευμένο μάλλον δεν ταιριάζει. Αν ξανακάνει compile, χάνεται το πλεονέκτημα της ταχύτητας. 
    Άλλο πρόβλημα είναι τα permissions των πινάκων. Το stored procedure μπορεί να φτιάχτηκε έχοντας permissions να διαβάσει τον Χ πίνακα. Αν του περάσεις τον Υ, τί θα πρέπει να κάνει? Αν ξανακάνει έλεγχο permissions, χάνεται πάλι το όφελος σε ταχύτητα.
    Το πρόβλημα αυτό δεν είναι μόνο του SQL Server. Απλά, τα stored procedures δεν είναι φτιαγμένα για να δουλεύουν σαν functions. Αν θέλεις να χρησιμοποιήσεις ένα παρόμοιο query σε διαφορετικούς πίνακες, καλύτερα να χρησιμοποιήσεις ένα code generator.
   
    Ανέφερες ότι μπορείς να περάσεις ένα cursor σαν παράμετρο. Το cursor δεν έχει καμμία σχέση με τους πίνακες. Θα πρέπει να το δεις σαν ένα recordset το οποίο είσαι αναγκασμένος να διαβάσεις γραμμή-γραμμή. Σκέψου το σαν να είχε επιλέξει ο query optimizer ένα πολύ αργό table scan με έξτρα καθυστερήσεις. Όταν λοιπόν περνάς ένα cursor είναι σα να περνάς ένα recordset. Το stored procedure περιμένει να διαβάσει κάποια πεδία ένα-ένα και δεν το ενδιαφέρει αν υπάρχουν περισσότερα από όσα περιμένει. Σημειωτέον, στην Oracle όπου τα cursors έχουν τύπο, δεν μπορείς να περάσεις ένα cursor που έχει διαφορετικά πεδία από αυτά που περιμένει το stored procedure. Από την έκδοση 9 και μετά βέβαια υπάρχει και ένας γενικός cursor.

    Γενικά οι cursors θεωρούνται "η ρίζα του κακού" για τα περισσότερα προβλήματα ταχύτητας στις databases. Να προτείνω δύο πολύ καλά βιβλία του Joe Celko, όπου περιγράφει πως να χρησιμοποιήσει κανείς SQL εκεί που νόμιζε ότι η μόνη λύση ήταν τα cursors: SQL For Smarties και το SQL Puzzles and Answers, and you will never write another cursor again!

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Mα όταν περνάω (υποθετικά) ένα table data type δεν έχει να κάνει πιστεύω με το execution plan γιατί δεν αφορά διαδιακασίες ανάγνωσης ή αλλοίωσης δεδομένων. Το table είναι στη μνήμη και το έχω ήδη γεμίσει. Τι αλλάζει με το να περνώ έναν integer ή ακόμη και ένα varchar; Αν χρειαστεί να κάνω σε αυτό JOIN ή άλλες data read-write διαδικασίες το execution plan πιστεύω δεν αλλάζει λόγω απουσίας indexes. Το πλήθος των δεδομένων σίγουρα παίζει ρόλο αλλά γιατί να μην το εκλάβει ως ένα table χωρίς indexes και χωρίς statistics; Φυσικά είναι προφανές ότι το structure του table θα είναι ορισμένο στην SP όπου θα καταλήκει σαν παράμετρος.

Οσο για τους cursors δε ζητάω τρελά πράγματα. Απλά έχω ανακαλύψει ότι αν φέρεις τα data σε ένα table data type και ανοίξεις cursor σε αυτό τα πράγματα επιταχύνονται. Υποκειμενική άποψη αλλά πιστεύω ότι ισχύει...

 Oοps! Τι ήταν αυτό με τα δικαιώματα; Μιλάω για μεταβλητή στη μνήμη, νομίζω ότι δεν έχει να κάνει με δικαιώματα.

ΑΑΑ! Τώρα κατάλαβα! Εννοείς να περνάει μόνο το table data type, όχι κάποιο πραγματικό πίνακα! Όμως, ένα table data type έχει και το ίδιο indexes και constraints οπότε όταν γίνεται compile το stored procedure, κάπως θα πρέπει να ξέρει ο optimizer τί execution plan να επιλέξει. Εξάλλου, ακόμα και χωρίς indexes ο optimizer θα αποφασίσει να κάνει table scan ή μπορεί να φτιάξει ένα hash index on-the-fly αν ο πίνακας που διαβάζει έχει μικρό μέγεθος. Όσο για τα statistics, θα τα υπολογίσει επί τόπου, γιατί διαφορετικά δεν θα ξέρει πως να υπολογίσει το σωστό execution plan.
    Φαντάζομαι όμως, ότι αν το table type μπορούσε να οριστεί εξωτερικά από το stored procedure, π.χ. σαν user-defined type, θα μπορούσε να περάσει και σαν παράμετρος ενός stored procedure. Για να γίνει αυτό όμως θα έπρεπε να λύθούν και θέματα όπως πότε καταστρέφεται το table data type? Θα χρησιμοποιηθεί reference counting? Garbage Collection? Κάτι άλλο?

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Να προσθέσω και γω κάτι που θα ήθελα πολύυυυ από τον SQL Server. Μια κολώνα όπως η RΟWNUM της Oracle που να έχει τον αύξοντα αριθμό του record (και φυσικά να παίζει και στα where....)

Στον SQL Server 2005 υπάρχει ένα νέο keyword που λέγεται ROW_NUMBER.  Δεν είναι ακριβώς κολώνα ενός πίνακα, αλλά μπορείς να το προσθέσεις σε οποιοδήποτε query σου και φαντάζομαι ότι λειτουργεί και στα where...  Δεν το έχω δοκιμάσει, αλλά θυμάμαι ότι κάπου το διάβασα!

---

Patrick