Καλησπέρα στην ομάδα!
Μετά από μια δεύτερη (και πιο νηφάλια) ματιά, διακρίνω πως το θέμα προσεγγίστηκε
λανθασμένα από το πρώτο κιόλας μήνυμα.
Αγαπητή Δέσποινα, είναι πολύ κακή πρακτική να διατηρούμε σε πολλαπλά σημεία
δεδομένα τα οποία χρησιμοποιούνται από την εφαρμογή μας.
Τα προβλήματα αυτής της τεχνικής, αναδεικνύει και ο καπετάν Γιώργος στο τελευταίο του μήνυμα.
Επίσης, η διαγραφή χρήσιμων δεδομένων, οδηγεί σε άγνοια δεδομένων και λανθασμένες αποφάσεις.
Μια παραγγελία, δεν είναι τίποτε άλλο από ένα πραγματικό γεγονός που αναμένει την εξέλιξή του.
Αυτή μπορεί να είναι ένα γεγονός ακύρωσης, αποστολής, πώλησης, ή ακόμα χειρότερα, επιστροφής.
Σε διαφορετικούς πίνακες θα πρέπει να κρατάμε τα στοιχεία κάθε γεγονότος (εξέλιξης) που σχετίζεται
με την κάθε παραγγελία και όχι την ίδια την παραγγελία.
Κανένα γεγονός δεν θα πρέπει να διαγράφεται από τον πίνακα παραγγελιών αλλά να "εξελίσσεται".
Με άλλα λόγια, μια παραγγελία πρέπει να επιδέχεται επεξεργασίας μόνο μέχρι να εμφανιστεί
στον πίνακα αποστολών ή ακυρώσεων.
Από τη στιγμή που αποσταλεί, μπορεί να εμφανιστεί στον πίνακα επιστροφών μόνο μέσα
σε ένα αποδεκτό χρονικό διάστημα (δικαίωμα επιστροφής).
Αν μια παραγγελία έχει αποσταλεί και δεν έχει επιστραφεί εντός του αποδεκτού διαστήματος
σημαίνει πως έχει καταλήξει σε μια επιτυχημένη πώληση.
Αυτή η φυσική ροή των γεγονότων θα πρέπει να εξασφαλίζεται μέσα από το περιβάλλον
χρήστη της εφαρμογής σου.
Νομίζω λοιπόν πως ένας τέτοιος σχεδιασμός, θα σου δώσει πολύ μεγαλύτερες δυνατότητες
στην ανάλυση των δεδομένων σου, διατηρώντας την ασφάλεια και την ακεραιότητά τους
σε πολύ υψηλά επίπεδα.
Τέλος, μπορεί να σου κάνω λίγο την καρδιά περιβόλι με τα παραπάνω αλλά πίστεψέ με…
να βοηθήσω θέλω.
Φιλικά, Γιάννης.