Γνωρίζει κανείς πως μπορούμε να ξεπεράσουμε το παραπάνω πρόβλημα του SQL Server 2000 + SP4. Η Microsoft για το παραπάνω πρόβλημα έιχε βγάλει το SP4 αλλά απλά απο 256 tables το κάνει 260 το όριο πινάκων σε ένα select statement.Επίσης να θεωρηθεί ότι δεν γίνεται να αλλάξουμε το view / query.Στο google που έψαξα κάποιοι κάνουνε μια stored procedure αλλά δεν κατάλαβα και πολλά.Ευχαρηστώ

---

select DATEDIFF(dd,GetDate(),'20140731') AS EΠΟΜΕΝΕΣ_ΔΙΑΚΟΠΕΣ

Το join πάνω από 260 πινάκων υποδηλώνει από μόνο του ένα πρόβλημα. Τώρα, δυο πιθανές λύσεις (μιας και δεν γίνεται να πειράξεις το query) είναι:

• Αναβάθμιση σε SQL Server 2005/2008 που υποστηρίζει πολύ περισσότερους πίνακες (δεν θυμάμαι πόσους αυτή τη στιγμή)
• Δημιουργία temp πίνακα που να περιέχει τα data από τους πρώτους 260 πίνακες και join των υπολοίπων σε αυτόν

Πάντως, ειδικά αν πρόκειται για reporting, η δεύτερη λύση μου φαίνεται αρκετά εφικτή. Ειδικά αν συνδυαστεί με ένα loading του temp πίνακα κατά τις low-utilization ώρες που λειτουργεί ο server. Παράλληλα, θα διευκολυνθεί ο server όταν θα πρέπει να τρέξει αυτά τα τεράστια queries.

---

Vir prudens non contra ventum mingit

Γιατί να θεωρηθεί? 

---

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

Είναι πολύ εύκολη η θεωρία αλλά δεν εχουμε κανένα query καρκίνο απλά έχουμε μερικά βασικά views και αρκετούς πίνακες καταλαβαίνεις ότι η βάση είναι μεγάλη με πολλά υποσυστήματα. Η αδυναμία της Microsoft στο να επιλύση το συγκεκριμένο πρόβλημα δεν σημαίνει ότι πρέπει αναγκαστικά να έχει προβλημα το query.Επίσης μου ακούγεται καλή ιδέα το παίξω με temporary πίνακα θα το δοκιμάσω.

---

select DATEDIFF(dd,GetDate(),'20140731') AS EΠΟΜΕΝΕΣ_ΔΙΑΚΟΠΕΣ

E, καλά όμως, μην γράφουμε ό,τι θέλουμε κι όλας... Το έχει επιλύσει ήδη από τον SQL Server 2005. Από εκεί και πέρα, δεν είπες αν πρόκειται για reporting σκοπούς. Γιατί σε αυτήν την περίπτωση η προτεινόμενη λύση είναι είτε να φτιαχθεί μια δεύτερη βάση που θα περιέχει τα data σε κατάλληλη μορφή denormalized, είτε ένα data mart.

---

Vir prudens non contra ventum mingit

Δεν είναι θεωρία αλλά πείρα. Έχω αντιμετωπίσει και στο παρελθόν τέτοια κατάσταση και έχω δουλέψει και με βάσεις με πολλές εκατοντάδες πίνακες. Σε όποια βάση και να δουλέψεις, ένα query το οποίο χρησιμοιεί 260 πίνακες είναι προβληματικό. Υπάρχουν πολύ μεγαλύτερα συστήματα όπως το SAP, με χιλιάδες πίνακες, τα οποία δεν πλησιάζουν καν το όριο των 260 πινάκων. Πέρα από υπερβολική πολυπλοκότητα ένα τέτοιο query θα έχει και κακό performance, ανεξαρτήτως βάσης, καθώς θα κλειδώσει πάρα πολλούς πίνακες για μεγάλο χρονικό διάστημα και θα μειώσει πάρα πολύ τα transactions που μπορούν να γίνουν ανά λεπτό.

---

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

Καταλαβαίνω απόλυτα και έχεις δίκαιο και στο πρώτο post που έγραψες και επίσης είναι δεδομένη η αναγνώριση της εμπειρίας στο πρόσωπο σου τουλάχιστον σε αύτο το forum.Απλά ίσως το διατύπωσα λάθος και ζητώ συγνώμη αν σε πρόσβαλα.Ναι το query σηκώνει βελτίωση δε λέω. Απλά θα ήθελα να έχω όλες τις εναλλκτικές απόψεις πρίν πάρω μια απόφαση και επειδή ήξερα ότι απο την αρχή θα έγραφε κάποιος ότι πρέπει να κάνω αλλαγή στο query για το λόγο αυτό είπα ας αποκλείσουμε αυτό το ενδεχόμενο.
   Στο θέμα μας τώρα. Βασικά δεν κατέληξα σε κάτι αλλά εξετάζω τις επιλογές που μου έδωσες εσύ και ο Kelman.Εκείνο που έχω να πώ είναι ότι πολύ συνάδελφοι σε ξένα forums έχουνε το ίδιο πρόβλημα με τον SQL 2000 κι όταν ένα προϊον δεν το αποσύρει η αγόρα εμείς είμαστε αναγκασμένοι να δείνουμε λύσεις.

---

select DATEDIFF(dd,GetDate(),'20140731') AS EΠΟΜΕΝΕΣ_ΔΙΑΚΟΠΕΣ