SQL Server (και άλλες databases)

Απ: Sorted Tables

cap — Fri, 19 May 2006 07:58:25 GMT

UPDATE: Αλέξανδρε, τελικά όπως θα δεις και στο post του Kelman, εδώ, ίσως να μην είναι η καλύτερη ιδέα, ειδικά αν θελήσεις αργότερα να αναβαθμίσεις στον SQL 2005.

Δυστυχώς δεν το γνώριζα αυτό τη στιγμή που σου έγραφα τα παραπάνω. Κρατησε μια σημείωση κάπου απλά για να το έχεις υπόψη σου αν γίνει κάποια στιγμή αναβάθμιση.

Απ: Sorted Tables

alexnir — Thu, 30 Mar 2006 15:49:52 GMT

Τα queries που τρεχουν για τον συγκεκριμενο πινακα δεν χρησιμοποιουν join.

Μεχρις τωρα απαντως που κανω καποιες δοκιμες (και αφου διορθωσα το προγραμμα) η λυση με τα views μου φανηκε παρα πολυ απλη, χρησιμη, σωστη.

Απ: Sorted Tables

cap — Thu, 30 Mar 2006 07:55:43 GMT

Δεν το γνώριζα αυτό, και μου φαίνεται πολύ σωστό. Βεβαια, στην περίπτωσή μας η χρήση indexes αφορούσε ένα μόνο πίνακα και όχι joins μεταξύ δύο ή περισσοτέρων πινάκων. Ομως, είναι ιδιαίτερα χρήσιμη πληροφορία την οποία σημειώνω (για να μπορώ και εγώ να "ψαρώνω" κανέναν που και που :) )

Απ: Sorted Tables

Παναγιώτης Καναβός — Thu, 30 Mar 2006 07:39:56 GMT

Γενικά, δεν μπορείς να βασίστείς στη σειρά με την οποία επιστρέφονται τα δεδομένα από ένα SQL query, εκτός και αν περιέχει ORDER BY. Ο τρόπος με τον οποίο γίνονται τα joins (hash joins, merge joins, nested loops) μπορεί να επιστρέψει τα δεδομένα με οποιαδήποτε σειρά, ακόμα και με την αντίθετη από αυτήν με την οποία βρίσκονται στο σκληρό. Για παράδειγμα, έστω ότι κάνεις join δύο πίνακες Α και Β, και έχεις ορίσει στον Α clustered index για να αναγκάσεις τα αποτελέσματα να επιστρέψουν με συγκεκριμένη σειρά. Ο query optimizer αποφασίζει να χρησιμοποιήσει nested loop, θεωρώντας εξωτερικό τον Β πίνακα, δηλαδή για κάθε γραμμή του Β πίνακα, θα επιστρέψει τις εγγραφές του Α που ήθελες να γυρίσουν με τη σειρά. Το τελικό αποτέλεσμα θα περιέχει τις εγγραφές του Β με τη σειρά αλλά του Α ανάμεικτα.

Τελικά, η χρήση views είναι η μόνη αξιόπιστη λύση αν δεν μπορείς να αλλάξεις τα αρχικά queries.

Απ: Sorted Tables

imanos — Thu, 30 Mar 2006 00:30:05 GMT

Αυτός ήταν ένας λόγος που είπα για clustered indexes .Μάλλον το περίμανα να γίνει αυτό.Φοβάμαι ότι δέν μπορείς να κάνεις και πολλά πράγματα.

'Ισως ο καλύτερος τρόπος είναι να Χρησιμοποιήσεις ORDER BY στα QUERIES σου

Απ: Sorted Tables

alexnir — Wed, 29 Mar 2006 22:55:12 GMT

γιατί άλλαξα όλα τα queries σε ενα πρόγραμμα (λόγω αλλαγής ονόματος table) και έιναι ποιο απλό να κάνω find and replace παρά να προσθέσω άλλη μια γραμμή.

αυτό που ήθελα στην αρχή να μάθω ήταν αν γινόταν να κάνω αλλαγή μόνο στην βάση (από enterprise manager)και όχι στο πρόγραμμα.

αυτος που το εφτιαξε το θεώρησε λεπτομέρια να sortαρει μάλλον.

οπότε από τις δυο περιπτωσεις με βόλεψε το view.

και δυστηχως τα queries που υπάρχουν είναι πάρα πολλά

Απ: Sorted Tables

KelMan — Wed, 29 Mar 2006 16:27:44 GMT

Τελικά όμως, γιατί είναι τόσο τρομερό το να βάζεις το ORDER BY που σε κάνει να χρησιμοποιήσεις το view;

Απ: Sorted Tables

alexnir — Wed, 29 Mar 2006 15:55:06 GMT

Κατ'αρχήν σας ευχαριστω παρα πολύ όλους!

Κάθησα το βράδυ και έπαιξα με την λύση Views και την λύση clustered indexes.

Ο πίνακας έχει πολλά inserts και για κάθε insert 2 υποχρεωτικά updates (υπάρχει πιθανότητα να γίνουν και περισσοτερα σε κάθε εγγραφή).

Ετσι κατέληξα στην λύση του view (και ευχαριστω παρα πολύ για το παράδειγμα cap).

Σας ευχαριστώ και πάλι όλους.

Αλέξανδρος

Απ: Sorted Tables

imanos — Wed, 29 Mar 2006 13:32:44 GMT

Μάνο χίλια συγνώμη

Απ: Sorted Tables

cap — Wed, 29 Mar 2006 04:44:12 GMT

KelMan wrote:

Σωτήρη, τα clustered indexes δεν προσφέρουν performance gain όταν γίνεται αναζήτηση για unique values καθώς δεν έχουν να κάνουν με τη μοναδικότητα των εγγραφών.

Εχμ, εχεις απόλυτο δίκιο. Ακυρο αυτό που είπα περι απόδοσης και clustered indexes.

Απ: Sorted Tables

KelMan — Wed, 29 Mar 2006 04:36:12 GMT

Σωστά, μπορώ να έχω ένα view με clustered index από κάτω, ονομάζονται indexed views. Στον SQL Server 2000 παίζουν σε Enterprise και Developer editions, στον 2005 σε όλες τις εκδόσεις.

Σωτήρη, τα clustered indexes δεν προσφέρουν performance gain όταν γίνεται αναζήτηση για unique values καθώς δεν έχουν να κάνουν με τη μοναδικότητα των εγγραφών.

Επίσης, σε ένα πίνακα με αρκετά OLTP operations, δεν αλλάζει δραματικά το performance αν μπει clustered index ή όχι. Έτσι κι αλλιώς η ύπαρξη του non-clustered index που θα βρίσκεται στο κλειδί ή στα κλειδιά, σημαίνει ότι κάθε Insert/Update/Delete θα πρέπει να παίξει με τα keys για να τοποθετήσει κάθε εγγραφή που αλλάζει στην κατάλληλη θέση. Αφήστε που τυπικά, οι πίνακες έχουν πολλαπλά indexes. Εξάλλου ο SQL Server έχει μηχανισμούς που μειώνουν το overehead που προκαλούν τα IUD στην αναδιοργάνωση των indexes. Πάντως, αντίθετα από αυτό που λένε και οι κινέζοι, καλύτερα πλούσιος και υγιής παρά φτωχός και άρρωστος, δεν μπορούμε να τα έχουμε όλα. Όντως τα πολλά indexes βελτιώνουν τα read operations και βλάπτουν τα write operations και γι αυτό αποτελεί τέχνη η επιλογή των σωστών indexes.

Παράκληση: Γιάννη, φώναζέ με Μάνο και όχι Μανώλη, δε μου αρέσει το δεύτερο...

Απ: Sorted Tables

imanos — Wed, 29 Mar 2006 04:11:46 GMT

Επίσης πρέπει να αναφέρουμε ότι clustered index υποστηρίζονται και σε views .

Μόνο στις SQL ENTERPRISE EDITION και DEVELOPER για το SQL2000 για τον 2005 επειδή δέν το έχω κοιτάξει μάλλον πρέπει ο Μανώλης να μας δώσει τα φώτα του.

Σημείωση.

Τα views πρέπει να κάνουν access μόνο σε DataTable και όχι άλλα views.

Απ: Sorted Tables

cap — Wed, 29 Mar 2006 04:10:21 GMT

imanos wrote:

Οπότε βλέπουμε ότι απλά by default ο SQL δημιουργεί έναν clustered index στο primary key όταν δέν υπάρχει άλλος clustered index δηλαδή ανάλογα μέ το τι δεδομένα θέλουμε περισσότερο να κάνουμε αναζητήσεις στον πίνακά μας πάνω σ'αυτά πρέπει να δηλώσουμε τον clustered index το οποίο μπορεί να μην είναι απαραίτητα το PRIMARY KEY

Δεν διαφωνώ, όπως ανέφερα και πιό πρίν και όπως είπαν ήδη και άλλοι συνάδελφοι, πάντοτε η απόφαση για το που θα χρησιμοποιηθεί το clustered index εξαρτάται από το είδος της χρήσης που κανείς επιθυμεί να κάνει στον πίνακα. Πιστεύω όμως οτι συμφωνούμε οτι σε ένα heavily-updated πίνακα, το να χρησιμοποιήσει κανείς το clustered index για να επιτύχει default sort order δεν αποτελεί βέλτιστη επιλογή μια και στερεί την απόδοση από τις αναζητήσεις που θα γίνονται με βάση το primary key του.

Σε περιπτώσεις heavily-read πινακα που δεν έχει ιδιαίτερα (ή καθόλου) updates, ενδέχεται η χρήση ενός clustered index για το default sort order να ωφελούσε την κατάσταση και στο θέμα της απόδοσης, εκτός της ταξινόμησης φυσικά.

Απ: Sorted Tables

imanos — Wed, 29 Mar 2006 04:05:11 GMT

Μανώλη νομίζω ότι κάλυψες πάρα πολύ ωραία το θέμα .

Ελπίζω να μπορέσαμε μέσα απο αυτή την συζήτηση να βοηθήσαμε αρκετά τον φίλο μας πάνω στο συγκεκριμμένο θέμα.

Απ: Sorted Tables

KelMan — Wed, 29 Mar 2006 03:54:23 GMT

Όπως είπε σωστά ο Σωτήρης, το primary key δεν πρέπει να είναι υποχρεωτικά clustered index. Μπορεί να είναι και σε μη clustered. Από default, όταν ορίζεις το primary key μέσα από τον Enterprise Manager, μπαίνει ως clusterd index. Προσθήκη: Επειδή το κάνει από default ο EM, δεν συνεπάγεται ότι είναι και η βέλτιστη λύση.

Άρα το ερώτημα είναι για ποιά πεδία προορίζονται τo clustered index ενός πίνακα. Η απόφαση για τι θα θέσουμε ως clustered key καθορίζεται σε πρώτη φάση αποκλειστικά και μόνο από τα queries που προβλέπουμε ότι θα τρέξουμε πάνω στον πίνακα. Τα queries που ευεργετούνται από το clustered index είναι (φυσικά) όσα έχουν το ORDER BY clause (ASCending ή DESCending, το ίδιο κάνει, δεν παίζει ρόλο) όπως επίσης και όλα όσα έχουν ranges τιμών πάνω στο πεδίο που έχουμε βάλει το clustered index. Προσθήκη: Πεδία που αποτελούν foreign keys (και κατ' επέκταση λαμβάνουν μέρος σε joins) δεν αποτελούν καλούς υποψήφιους για clustered indexes.

Για παράδειγμα, αν έχω έναν πίνακα με κλειδί το πεδίο ProductID και έχω queries με WHERE clause του τύπου "WHERE ProductID=X" καθώς και του τύπου "WHERE ProductDate>FromDate AND ProductDate<ToDate" είναι σαφώς προτιμότερο να βάλω το clustered index στο πεδίο ProductDate και όχι στο ProductID.

Η ρύθμιση σωστών indexes παίζει πολύ μεγάλο ρόλο για το performance της εφαρμογής και δεν πρέπει να τη σπαταλήσουμε επιπόλαια απλά και μόνο πάνω σε κάποιο πεδίο βάσει του οποίου θα θέλαμε να βλέπουμε default ταξινόμηση, εκτός αν συμβαδίζει αυτή η επιθυμία με την προηγούμενη λογική. Οι επιθυμίες αλλάζουν, μπορεί αύριο να θέλουμε να τα βλέπουμε διαφορετικά ταξινομημένα, τι θα κάνουμε τότε; DROP και recreate τα indexes; Η default ταξινόμηση των clustered indexes θα πρέπει να εκλαμβάνεται ως side-effect και όχι ως feature. Ας μην ξεχνάμε ότι η σχεσιακή θεωρία λέει ότι δεν πρέπει να υπολογίζουμε ότι θα πάρουμε τα δεδομένα με καμία συγκεκριμένη σειρά, αν θέλουμε ταξινόμηση, τότε τη ζητάμε (με το ORDER BY) ή την κάνει ο client όπως είπε ο Γιάννης.