https://www.dotnetzone.gr:443/cs/forums/73/ShowForum.aspxΓια όσους κάνουν τα πρώτα τους βήματα στην Microsoft Access ή τον SQL Server, ή γενικότερα στη θεωρία βάσεων δεδομένων.elCommunityServer 2.1 SP3 (Build: 20423.1)https://www.dotnetzone.gr:443/cs/forums/thread/50397.aspxFri, 01 May 2009 05:37:55 GMT2622095e-976c-431a-859e-16783ec7ecd7:50397Bill 0https://www.dotnetzone.gr:443/cs/forums/thread/50397.aspxhttps://www.dotnetzone.gr:443/cs/forums/commentrss.aspx?SectionID=73&PostID=50397Καταλαβαίνω απόλυτα και έχεις δίκαιο και στο πρώτο post που έγραψες και επίσης είναι δεδομένη η αναγνώριση της εμπειρίας στο πρόσωπο σου τουλάχιστον σε αύτο το forum.Απλά ίσως το διατύπωσα λάθος και ζητώ συγνώμη αν σε πρόσβαλα.Ναι το query σηκώνει βελτίωση δε λέω. Απλά θα ήθελα να έχω όλες τις εναλλκτικές απόψεις πρίν πάρω μια απόφαση και επειδή ήξερα ότι απο την αρχή θα έγραφε κάποιος ότι πρέπει να κάνω αλλαγή στο query για το λόγο αυτό είπα ας αποκλείσουμε αυτό το ενδεχόμενο.<br>&nbsp;&nbsp; Στο θέμα μας τώρα. Βασικά δεν κατέληξα σε κάτι αλλά εξετάζω τις επιλογές που μου έδωσες εσύ και ο Kelman.Εκείνο που έχω να πώ είναι ότι πολύ συνάδελφοι σε ξένα forums έχουνε το ίδιο πρόβλημα με τον SQL 2000 κι όταν ένα προϊον δεν το αποσύρει η αγόρα εμείς είμαστε αναγκασμένοι να δείνουμε λύσεις.<br>https://www.dotnetzone.gr:443/cs/forums/thread/50395.aspxFri, 01 May 2009 04:06:06 GMT2622095e-976c-431a-859e-16783ec7ecd7:50395Παναγιώτης Καναβός0https://www.dotnetzone.gr:443/cs/forums/thread/50395.aspxhttps://www.dotnetzone.gr:443/cs/forums/commentrss.aspx?SectionID=73&PostID=50395Δεν είναι θεωρία αλλά πείρα. Έχω αντιμετωπίσει και στο παρελθόν τέτοια κατάσταση και έχω δουλέψει και με βάσεις με πολλές εκατοντάδες πίνακες. Σε όποια βάση και να δουλέψεις, ένα query το οποίο χρησιμοιεί 260 πίνακες είναι προβληματικό. Υπάρχουν πολύ μεγαλύτερα συστήματα όπως το SAP, με χιλιάδες πίνακες, τα οποία δεν πλησιάζουν καν το όριο των 260 πινάκων. Πέρα από υπερβολική πολυπλοκότητα ένα τέτοιο query θα έχει και κακό performance, ανεξαρτήτως βάσης, καθώς θα κλειδώσει πάρα πολλούς πίνακες για μεγάλο χρονικό διάστημα και θα μειώσει πάρα πολύ τα transactions που μπορούν να γίνουν ανά λεπτό.<div><br></div><div>Μία λύση είναι όντως να δουλέψεις με temporary πίνακα, και αφού δέχεσαι να το κάνεις αυτό υποθέτω ότι το query μπορεί τελικά να αλλάξει. Μία πολύ καλύτερη λύση, αυτή που χρησιμοποιείται σε όσες εφαρμογές έχουν πολλούς πίνακες και μεγάλο όγκο δεδομένων, είναι να φτιάξεις μία ξεχωριστή βάση με σχήμα φτιαγμένο ειδικά για reporting. Είτε περιοδικά, είτε μέσω κάποιου trigger ή queue, περνάς τις αλλαγές από την transactional στην reporting βάση. Αυτή είναι και η λύση που χρησιμοποιούν και μεγάλες εφαρμογές όπως το SAP αλλά και μικρότερες όπως π.χ. ο Project Server. Έτσι πετυχαίνεις ταχύτητα τόσο για την transactional όσο και για την reporting database αλλά και πολύ ευκολότερη δημιουργία των reports. Τέλος μπορείς να χρησιμοποιήσεις τα Analysis Services για να πετύχεις ακόμα μεγαλύτερη ταχύτητα σε reports που απαιτούν aggregations π.χ. σε επίπεδο εβδομάδας-μήνα-χρόνου, πόλης-νομού-χώρας και όλων των συνδυασμών που μπορείς να φανταστείς.</div><div><br></div><div><br></div><div><div><div>Το μόνο στο οποίο έχεις ένα μερικό δίκιο είναι στο ότι η Microsoft δεν πρόκειται να κάνει τίποτε παραπάνω για τον SQL Server 2000, όχι λόγω αδυναμίας αλλά επειδή το προϊόν έχει αποσυρθεί πλέον.</div></div></div>https://www.dotnetzone.gr:443/cs/forums/thread/50386.aspxThu, 30 Apr 2009 19:05:42 GMT2622095e-976c-431a-859e-16783ec7ecd7:50386KelMan0https://www.dotnetzone.gr:443/cs/forums/thread/50386.aspxhttps://www.dotnetzone.gr:443/cs/forums/commentrss.aspx?SectionID=73&PostID=50386E, καλά όμως, μην γράφουμε ό,τι θέλουμε κι όλας... Το έχει επιλύσει ήδη από τον SQL Server 2005. Από εκεί και πέρα, δεν είπες αν πρόκειται για reporting σκοπούς. Γιατί σε αυτήν την περίπτωση η προτεινόμενη λύση είναι είτε να φτιαχθεί μια δεύτερη βάση που θα περιέχει τα data σε κατάλληλη μορφή denormalized, είτε ένα data mart.https://www.dotnetzone.gr:443/cs/forums/thread/50385.aspxThu, 30 Apr 2009 18:56:42 GMT2622095e-976c-431a-859e-16783ec7ecd7:50385Bill 0https://www.dotnetzone.gr:443/cs/forums/thread/50385.aspxhttps://www.dotnetzone.gr:443/cs/forums/commentrss.aspx?SectionID=73&PostID=50385Είναι πολύ εύκολη η θεωρία αλλά δεν εχουμε κανένα query καρκίνο απλά έχουμε μερικά βασικά views και αρκετούς πίνακες καταλαβαίνεις ότι η βάση είναι μεγάλη με πολλά υποσυστήματα. Η αδυναμία της Microsoft στο να επιλύση το συγκεκριμένο πρόβλημα δεν σημαίνει ότι πρέπει αναγκαστικά να έχει προβλημα το query.Επίσης μου ακούγεται καλή ιδέα το παίξω με temporary πίνακα θα το δοκιμάσω.<br>https://www.dotnetzone.gr:443/cs/forums/thread/50383.aspxThu, 30 Apr 2009 18:37:32 GMT2622095e-976c-431a-859e-16783ec7ecd7:50383Παναγιώτης Καναβός0https://www.dotnetzone.gr:443/cs/forums/thread/50383.aspxhttps://www.dotnetzone.gr:443/cs/forums/commentrss.aspx?SectionID=73&PostID=50383Γιατί να θεωρηθεί?&nbsp;<div><br></div><div>Όταν εμπλέκεις 260 πίνακες σε ένα query σημαίνει δύο πράγματα και ουσιαστικά ένα. Έχεις ένα πάρα -πάρα πολύ κακό query. Αυτό μπορεί να συμβαίνει είτε επειδή κάποιος έφτιαξε ένα τεράστιο query και έβαλε μέσα και τους 260 πίνακες, ή ότι μία σειρά προγραμματιστών αντί να φτιάχνουν κάθε φορά σωστά queries, έπιαναν ένα view που βόλευε ελαφρώς και το έχωναν σε άλλο με αποτέλεσμα κάποια στιγμή να φτάσει το όριο των 260 πινάκων, πολλοί από τους οποίους επαναλαμβάνοντας 7-8 φορές.</div><div><br></div><div>Όπως και να έχει, έχεις ένα query-καρκίνο και καμμία ασπιρίνη δεν πρόκειται να σε σώσει αν δεν το ξεφορτωθείς. Το πρόβλημα δεν είναι της Microsoft ούτε του 2000. Μπορεί ο SQL 2005 και ο 2008 να έχουν αυξήσει το όριο, αλλά με τέτοιο κακό κώδικα, σύντομα θα ξεπεράσετε οποιοδήποτε είναι το νέο όριο.</div><div><br></div><div>Η μόνη λύση είναι να σταματήσετε άμεσα να χώνετε views το ένα μέσα στο άλλο για λόγους "ευκολίας" και να καθαρίσετε το σχήμα της βάσης. Τα νέα views θα πρέπει να γράφονται χτυπώντας είτε τους πίνακες είτε ένα σετ από συγκεκριμένα, βασικά views.</div><div><br></div><div><br></div><div>Υ.Γ. Αν μου πεις και ότι δουλεύεις σε εταιρεία που φτιάχνει χρηματιστηριακό software ...</div>https://www.dotnetzone.gr:443/cs/forums/thread/50382.aspxThu, 30 Apr 2009 18:36:24 GMT2622095e-976c-431a-859e-16783ec7ecd7:50382KelMan0https://www.dotnetzone.gr:443/cs/forums/thread/50382.aspxhttps://www.dotnetzone.gr:443/cs/forums/commentrss.aspx?SectionID=73&PostID=50382<P>Το join πάνω από 260 πινάκων υποδηλώνει από μόνο του ένα πρόβλημα. Τώρα, δυο πιθανές λύσεις (μιας και δεν γίνεται να πειράξεις το query) είναι:</P> <UL> <LI>Αναβάθμιση σε SQL Server 2005/2008&nbsp;που υποστηρίζει πολύ περισσότερους πίνακες (δεν θυμάμαι πόσους αυτή τη στιγμή)</LI> <LI>Δημιουργία temp πίνακα που να περιέχει τα data από τους πρώτους 260 πίνακες&nbsp;και&nbsp;join των υπολοίπων σε αυτόν</LI></UL> <P>Πάντως, ειδικά αν πρόκειται για reporting, η δεύτερη λύση μου φαίνεται αρκετά εφικτή. Ειδικά αν συνδυαστεί με ένα loading του temp πίνακα κατά τις&nbsp;low-utilization ώρες που λειτουργεί ο server. Παράλληλα, θα διευκολυνθεί ο server όταν θα πρέπει να τρέξει αυτά τα τεράστια queries.</P>https://www.dotnetzone.gr:443/cs/forums/thread/50378.aspxThu, 30 Apr 2009 18:22:01 GMT2622095e-976c-431a-859e-16783ec7ecd7:50378Bill 0https://www.dotnetzone.gr:443/cs/forums/thread/50378.aspxhttps://www.dotnetzone.gr:443/cs/forums/commentrss.aspx?SectionID=73&PostID=50378&nbsp; Γνωρίζει κανείς πως μπορούμε να ξεπεράσουμε το παραπάνω πρόβλημα του SQL Server 2000 + SP4. Η Microsoft για το παραπάνω πρόβλημα έιχε βγάλει το SP4 αλλά απλά απο 256 tables το κάνει 260 το όριο πινάκων σε ένα select statement.Επίσης να θεωρηθεί ότι δεν γίνεται να αλλάξουμε το view / query.Στο google που έψαξα κάποιοι κάνουνε μια stored procedure αλλά δεν κατάλαβα και πολλά.Ευχαρηστώ<br><br>