Μου φαίνεται ότι το τι πρέπει να κάνεις εξαρτάται ανά περίπτωση και ουσιαστικά εκεί είναι όλη η ουσία της αρχιτεκτονικής της λύσης... Μπορεί τα 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