αναπτύσουμε τον τελευταίο καιρό μια εφαρμογή. έχουμε έναν πίνακα με αρκετά varchar πεδία. Προέκειψε η ανάγκη τα πεδία αυτά να αυξηθούν σε μέγεθος και πλέον υπάρχει το ενδεχόμενο αρκετά μεγάλο ποσοστό εγγραφών του πίνακα (πάνω από 50%) να κάνει row-overflow. Ο πίνακας αυτός δεν γίνεται delete, δεν  θα γίνεται συχνά update και δεν ενδιαφέρει ιδιαίτερα η ταχύτητα του. Θα γίνεται όμως πολύ συχνά select και εκεί η ταχύτητα ενδιαφέρει πολύ!!

Έχω λοιπόν τις εξής επιλογές και θέλω τη γνώμη σας ποια να ακολουθήσω:

1. Κάνω την πάπια (παλιά, κλασσική μέθοδος με γνωστά δοκιμασμένα αποτελέσματα)
2. Σπάω μόνος μου τον πίνακα σε πολλούς (vertical partioting δεν λέγεται;), φτιάχνω ένα view που τους διαβάζει όλους και φτιάχνω triggers για το view ώστε να έχω το Update,delete functionallity. Ωραίο ακούγεται
3. Κρατάω τις πληροφορίες σε αρχεία και αποθηκεύω το path. Προβληματικό από πάρα πολλές πλευρές, αυτή τη στιγμή είναι η τελευταία επιλογή
4. κατί άλλο;

Μάριος

υγ. Αν υπάρχει κανένα άρθρο (εκτός από αυτό στο BOL) θα το εκτιμούσα ιδιαιτέρως

καλησπέρα Μάριε

Πριν απαντήσω έχω μια ερώτηση

Πιο είναι το RDMS που χρησιμοποιείς???????

SQL 2000 OR 2005

---

Antonios Chatzipavlis

SQL Server 2005.

Το development γίνεται στο developer edition αλλά το production platform δεν ξέρω ποια ακριβώς έκδοση θα είναι (για workgroup το βλέπω)

ok

Στον 2005 υπάρχει το datatype varchar(max), nvarchar(max) το οποίο σου δίνει την δυνατότητα που θέλεις χωρίς να πειράξεις την λογική σου. Το καλό με τον τύπο αυτό είναι ότι ναι μεν μπορείς να αποθηκεύσεις δεδομένα μέχρι 2GB με την αρχιτεκτονική που είχε μέχρι τώρα ο sql server αλλά δεν το κάνει από την αρχή εαν τα περιεχόμενα χωράνε στη σελίδα τότε μπαίνουν σε αυτή αν όχι τοτε βάζει στη γραμμή ένα 16bit pointer που δείχνει σε ένα δεντρο με nodes. Αν μετά αλλάξεις το περιεχόμενο σε κάτι που χωράει να μπει στην σελίδα τότε σβήνει τις επιπλέον σελίδες και βάζει το περιέχομενο στην γραμμη. Ιδιαίτερο κόστος στο performance των select queries δεν έχεις έαν μάλιστα το αντιπαραθέσεις με την λογική των joins είναι χωρίς αμφιβολία καλύτερο. Σε πειράματα που έκανα είδα ότι η επιβάρυνση είναι 2-3% βλέποντας το query cost & το execution plan.

Βέβαια πρέπει να επισυμάνω ότι ένα τέτοιο πεδίο δεν γίνεται index και αν δεν με απατάει η μνήμη μου παίζει σε όλες τις εκδόσεις του sql server αλλά δες το για σιγουριά

---

Antonios Chatzipavlis

Πρακτικά η λογική είναι ίδια απλά αν δεν χωράει μέσα στη γραμμή το βάζει σε δέντρο αντί για το row-overflow. Αν η επιβάρυνση είναι μόνο 2-3% δεν υπάρχει μεγάλο πρόβλημα αλλά θα ήθελα να σε ρωτήσω κάτι:

Το ποσοστό αυτό βγήκε σε production περιβάλλον; με πολλές βάσεις να συναγωνίζονται για ΙΟ memory και ΙΟ reads;

ευχαριστώ για τη βοήθεια
Μάριος

υγ: Και να μπορούσα δεν θα έκανα index τέτοια πεδία

Μάριε

Το περιβάλλον στο οποίο εγώ έκανα τα πειράματα μου ήταν αρκετά καλό. Εντάξει δεν ήταν Heavy duty αλλά δεν ήταν για πέταμα.

Όπως και να έχει πάντως είναι πολύ καλύτερο από το να κάνεις join queries.

---

Antonios Chatzipavlis

ok, δεκτό. Μια τελευταία ερώτηση:

διάβασα σε ένα blog στο msdn ότι την sqlParameter για το πεδίο τύπου varchar(max) πρέπει να την περάσω με size= -1 ίσχύει αυτό; λίγο παράξενο μου φαίνεται. βέβαια αναφερόταν σε output parameter όπου δεν έχει σημασία το size.

ΝΑΙ

και αυτό γιατί το property είναι σε bytes. Φαντάσου τον αριθμό που θα έπρεπε να γράψεις...

Έτσι βάλανε -1 γιατί αρνητικές τιμές σε μέγεθος πεδίου όπως και να το κάνουμε δεν γίνεται

---

Antonios Chatzipavlis

Αντώνη, ευχαριστώ πολύ

το δοκίμασα από εχθές κιόλας και παίζει μια χαρά, το μόνο που χρειάστηκε να κάνω ήταν να αλλάjω τον τύπο των πεδίων και των παραμέτρων στα stored procedures.

Να είσαι καλά

Ο μικρός στην φώτο δικός σου είναι πόσο ετών είναι;

---

Antonios Chatzipavlis