Στο concept των smart clients, τα δεδομένα του χρήστη μένουν αποθηκευμένα στο μηχάνημά του ώστε να μπορεί να δουλεύει και off-line. Σύμφωνα με όσα έχω καταλάβει από τα παραδείγματα της Microsoft και από όσα έχω βρει περιοδικά στο web, χρησιμοποιείται ένα dataset για να κράταει όλα τα δεδομένα το οποίο ο client το γεμίζει και το ενημερώνει σε κάθε ευκαιρία, ενώ το χρησιμοποιεί σαν off line database όσο είναι offline (αποθηκεύοντάς στο πιθανώς και στο δίσκο μεταξύ των sessions).

Όταν έχουμε περιπτώσεις μεγάλων βάσεων όμως τι κάνουμε (με το μεγάλες αναφέρομαι στο schema, μεγάλο αριθμό πινάκων κλπ); Σίγουρα ξεχωρίζουμε τα readonly reference data τα οποία τα διαχειριζόμαστε ξεχωριστά. Αν τα transient data όμως παραμένουν πολλά, υπάρχει κάποιο best practice που υπάρχει για τη διαχείρισή τους; Πρέπει να βάλουμε τους πίνακες αυτούς σε ένα τεράστιο dataset, μαζί με τις αλληλοσυνδέσεις τους; Το σπάμε σε κομμάτια; Τι γίνεται με τα references μεταξύ διαφορετικών κομματιών;

Επίσης, τι γίνεται στην περίπτωση που χρειάζομαι δεδομένα από 10 διαφορετικούς πίνακες; Σε άλλες καταστάσεις ενδέχεται να έφτιαχνα ένα view στην db που να τα μαζεύει. Λόγω της δομής που πρέπει να κρατήσω με ένα μεγάλο dataset, πρέπει να τραβήξω 10 selects, σε κάθε έναν από τους πίνακες για να γεμίσω "μερικώς" (ίσως enforce constrains = false) το dataset και να το στείλω στον client. Πως επηρεάζει αυτό τον sql server μου;

Η περίπτωση που έχω στο μυαλό μου για εφαρμογή, αφορά οντότητες οι οποίες εμπλέκουν τουλάχιστον 20 πίνακες οι οποίοι σύμφωνα με το αρχικό απλοϊκό σκεπτικό θα έπρεπε να μπούνε σε ένα dataset.

Ότι παράδειγμα έχω βρει μέχρι τώρα, έχει τελείως απλοικές καταστάσεις με πολύ απλά datasets...

Όποιος ξέρει απαντήσεις ή έχει βρει κάτι καλύτερο στο web, ας πει κάτι...

PS.
1. Από datasets δεν ξεκολάει η κατάσταση
2. Performance μεταφοράς δεδομένων έχει εξεταστεί, πέφτει συμπίεση.
3. Όλο το handling για τα readonly (ή σπανίως ενημερώσημα) δεδομένα είναι ήδη υλοποιημένο με αρκετά αποδοτικό τρόπο, εκτενές caching και συμπίεση.

---

Χρήστος Γεωργακόπουλος

Μου φαίνεται ότι το τι πρέπει να κάνεις εξαρτάται ανά περίπτωση και ουσιαστικά εκεί είναι όλη η ουσία της αρχιτεκτονικής της λύσης... Μπορεί τα specs να επιτρέπουν την πλήρη off-line εργασία, μπορεί την μερική/περιορισμένη, μπορεί και και να μην την επιτρέπουν.

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

Τώρα, σε αυτό το σενάριο μπαίνουν τόσα πολλά IF που μπορεί τελικά να μην είναι υλοποιήσιμο το σενάριο off-line working. Πόσα προϊόντα πουλάει ο πωλητής; 10, 100 ή 10.000; Πόσο συχνά μπαίνουν νέα προϊόντα και αφαιρούνται παλαιότερα; Πόσους πελάτες επισκέπτεται την ημέρα; Είναι partitioned οι πελάτες με κάποιο τρόπο (γεωγραφικά/ανά πωλητή/ανά business/κλπ); Πόσο συχνό συγχρονισμό θέλουμε να έχουμε με τη βάση; Πως θα επιλύσουμε τα conflicts;

Πάντως, όπως και να έχει το dataset δεν έχει φτιαχτεί προκειμένου να αντιγράφουμε όλο το schema και όλα τα data στη μνήμη… Όπως επίσης, δεν παίζει ρόλο το πλήθος των πινάκων που κρατάει, αλλά το πλήθος των operations που θα γίνουν και τα business rules κάτω στα οποία θα κινείται η λογική των conflicts… Είναι προτιμότερο να έχω 50 πίνακες με 10 εγγραφές όλες-όλες μόνο για insert, παρά 3 πίνακες με πολλά inserts/update/deletes, όπου τα operations του «regional salesman» έχουν προτεραιότητα σε σχέση με αυτά του απλού salesman εκτός από την περίπτωση που ο απλός salesman έχει κάνει ένα volume παραγγελιών μεγαλύτερο από αυτό του regional manager (έτσι τώρα μου ήρθε αυτό το rule).

Το πέρασμα από την On-line-κλειδώνω-τα-records-και-όποιον-πάρει-ο-χάρος λογική στην off-line-έχε-πρόχειρα-τα-ponstan λογική έχει ακριβώς αυτή τη δυσκολία. Εδώ και χρόνια έχουμε συνηθίσει να σκεφτόμαστε και να υλοποιούμε τη σχεδίαση σε επίπεδο βάσης έχοντας ως δεδομένο ότι "μπορώ από έναν πίνακα να πάρω ανά πάσα στιγμή τα data μέσω ενός τετραπλού join". Για σκέψου όμως ότι αν θα έπρεπε να κρατήσεις τα look-up data στο ελάχιστο ή αν θα έπρεπε να σπάσεις τα data σου σε partitions ώστε να ελαφρύνεις τον όγκο της πληροφορίας, τότε πως θα σχεδίαζες τη βάση;

Αν θέλεις, μπορείς να μας περιγράψεις πιο αναλυτικά την περίπτωση που έχεις στο μυαλό σου να την κουβεντιάσουμε ως άσκηση… Θα έχει πολύ ενδιαφέρον…

 

 

---

Vir prudens non contra ventum mingit

Μιλάμε για ασφαλιστικά συμβόλαια. Τα δεδομένα είναι λίγα στην περίπτωση που εφαρμόζω αυτή τη στιγμή, αλλά οι πίνακες είναι πολλοί. Θέλει ο client να διορθώσει κάτι σε ένα συμβόλαιο. Του γεμίζω το dataset-τέρας με 1-3 γραμμές σε κάθε πίνακα και του το στέλνω. Όταν τελιώσει μου το γυρίζει και αν δεν υπάρχει conflict θα μπει στη βάση. Αλλά το ότι το συμβόλαιο μπλέκει 20 πίνακες που θα μπουν σε ένα dataset με τρομάζει... Και τα 20 selects με φοβίζουν κάπως... Για τα updates/inserts δεν τρέχει τίποτα, έτσι κι αλλιώς με getchanges θα δουλέψει...

---

Χρήστος Γεωργακόπουλος

Πέρα από τον ψυχολογικό παράγοντα δεν βλέπω που είναι το πρόβλημα... Έχεις ελέγξει το τυπικό μέγεθος (σε KB) που θα έχει το dataset μέσα από το Studio? Επίσης, μπορείς να βάλεις μέσα στο dataset κάποιους βασικούς πίνακες που θα χρειαστείς και κατόπιν να ετοιμάσεις views. Μπορεί να σου δώσουν μικρότερο όγκο data. Π.χ αν έχεις ένα grid που εμφανίζει data από 6 πίνακες, δείχνοντας ένα column από τον καθένα, ενδέχεται το view να έχει μικρότερο όγκο, παρ' όλο που θα έχεις columns με πανομοιότυπη πληροφορία. Θέλει proof-of-point δοκιμές για να δεις τι σε συμφέρει καλύτερα...

---

Vir prudens non contra ventum mingit

By the way, έκανα δοκιμές σε production περιβάλλον για το θέμα των πολλαπλών reads από πίνακες για να γεμίσει το γαιδουροdataset. Το αποτέλεσμα ήταν ότι από το να γεμίσω ένα view με τις πληροφορίες που θέλω από 15 βαρβάτους πίνακες, συμφέρει απείρως περισσότερο σε performance να ρίξω 15 διαφορετικά selects, ένα σε κάθε πίνακα. Πήρα μέχρι και 75% γρηγορότερα τα αποτελέσματα που ήθελα. (χωρίς να καταργήσω τελείως τα joins στα σπαστά selects, πάντα τo κριτήριο για το select ήταν το ίδιο, τιμή από clustered index στον μπαμπά πίνακα)

Η μόνη διαφορά με την πραγματική κατάσταση, είναι ότι έφερα μόνο τα δεδομένα που ήθελα να δώ. Στην περίπτωση γαιδουροdataset θα πρέπει οι 15 πίνακες να γεμίζουν και με δεδομένα που δεν θέλεις να δεις, οπότε αυτό ίσως επιβαρύνει ακόμα και το 75% που κερδίζεις από τα σπαστά selects (και λόγω extra φόρτου του SQL και λόγω καθυστέρησης στη μεταφορά των δεδομένων στον client). Θα κάνω μερικά tests και θα σας πω τα αποτελέσματα... (Σε normalized βάσεις ίσως δεν είναι τόσο πρόβλημα, αλλά αν στον σχεδιασμό της βάσης έχει βάλει το χεράκι του δεινόσαυρος-coboλίστας, τότε έχουμε περίπτωση Ζαχαρία.... (Σωτήρη γράψε κάτι))

Πάντως συνεχίζει να με τρομάζει η κατάσταση... στην ουσία θα έχω ένα dataset με όλο το schema της βάσης; Σίγουρα απλοποιεί πάρα πολλά πράγματα... BUT.... BUT... BUT.... Δεν ξέρω τι έχει μέσα αυτό το BUT, αλλά δεν μου κάθεται καλά... Ρίχτε καμιά άποψη για επιπτώσεις στα resources του client ή για άλλα drawbacks...

Κι αυτή η microsoft ρε παιδί μου είχε μια ιδέα που την είπε "smart clients" και την έχει αφήσει στο έλεος του θεού... ούτε ένα παράδειγμα της προκοπής, ούτε ένα σοβαρό case study.... θα τρέξει αυτό το πράγμα ή θα μας τη βγεί με κάνα άλλο σενάριο; Και εδώ μέσα που ρωτάω δηλαδή... τρίχες κατσαρές σχεδόν... βαδίζω σε αχαρτογράφητα νερά και ίσως πρέπει να κάνω πίσω....

Να φλυαρίσω άλλη μια παραγραφούλα ακόμα, αλλά το σκεπτικό πιστεύω είναι: "λύσε το όπως θα σκεφτόταν η microsoft να το λύσει". Αν βαδίζεις έτσι έχεις λιγότερες πιθανότητες να φας τα μούτρα σου. Και το θέμα smart clients μάλλον η microsoft δεν το έχει σκεφτεί αρκετά...

---

Χρήστος Γεωργακόπουλος