Στοιχεία απο πίνακα σε πίνακα

[kapetang]

Φίλε Τάσο, μάλλον δεν έγινα αντιληπτός.
Φυσικά και δε θα γίνεται καμία επεξεργασία άμεσα από το χρήστη στον πίνακα αρχείο (Β).
Ο χρήστης εργάζεται (προσθέτει, διαγράφει και τροποποιεί εγγραφές) στο βασικό πίνακα (Α).
Όμως αφού μεταφέρουμε από τον (Α) κάποιες εγγραφές στον πίνακα (Β) και τις σημειώσουμε στον (Α) ως αρχειοθετημένες, ενδέχεται ο χρήστης να τις τροποιήσει (στον Α).
Τότε οι εγγραφές αυτές δε θα είναι ίδιες στον (Α) και τον (Β).
Για το λόγο αυτό προτείνω την ενημέρωση.

Φιλικά/Γιώργος

[nisgia]

Καλησπέρα στην ομάδα!

Μετά από μια δεύτερη (και πιο νηφάλια) ματιά, διακρίνω πως το θέμα προσεγγίστηκε
λανθασμένα από το πρώτο κιόλας μήνυμα.

Αγαπητή Δέσποινα, είναι πολύ κακή πρακτική να διατηρούμε σε πολλαπλά σημεία
δεδομένα τα οποία χρησιμοποιούνται από την εφαρμογή μας.
Τα προβλήματα αυτής της τεχνικής, αναδεικνύει και ο καπετάν Γιώργος στο τελευταίο του μήνυμα.
Επίσης, η διαγραφή χρήσιμων δεδομένων, οδηγεί σε άγνοια δεδομένων και λανθασμένες αποφάσεις.

Μια παραγγελία, δεν είναι τίποτε άλλο από ένα πραγματικό γεγονός που αναμένει την εξέλιξή του.
Αυτή μπορεί να είναι ένα γεγονός ακύρωσης, αποστολής, πώλησης, ή ακόμα χειρότερα, επιστροφής.
Σε διαφορετικούς πίνακες θα πρέπει να κρατάμε τα στοιχεία κάθε γεγονότος (εξέλιξης) που σχετίζεται
με την κάθε παραγγελία και όχι την ίδια την παραγγελία.
Κανένα γεγονός δεν θα πρέπει να διαγράφεται από τον πίνακα παραγγελιών αλλά να "εξελίσσεται".

Με άλλα λόγια, μια παραγγελία πρέπει να επιδέχεται επεξεργασίας μόνο μέχρι να εμφανιστεί
στον πίνακα αποστολών ή ακυρώσεων.
Από τη στιγμή που αποσταλεί, μπορεί να εμφανιστεί στον πίνακα επιστροφών μόνο μέσα
σε ένα αποδεκτό χρονικό διάστημα (δικαίωμα επιστροφής).
Αν μια παραγγελία έχει αποσταλεί και δεν έχει επιστραφεί εντός του αποδεκτού διαστήματος
σημαίνει πως έχει καταλήξει σε μια επιτυχημένη πώληση.

Αυτή η φυσική ροή των γεγονότων θα πρέπει να εξασφαλίζεται μέσα από το περιβάλλον
χρήστη της εφαρμογής σου.

Νομίζω λοιπόν πως ένας τέτοιος σχεδιασμός, θα σου δώσει πολύ μεγαλύτερες δυνατότητες
στην ανάλυση των δεδομένων σου, διατηρώντας την ασφάλεια και την ακεραιότητά τους
σε πολύ υψηλά επίπεδα.

Τέλος, μπορεί να σου κάνω λίγο την καρδιά περιβόλι με τα παραπάνω αλλά πίστεψέ με…
να βοηθήσω θέλω.

Φιλικά, Γιάννης.

[Tasos]

Φίλε Τάσο, μάλλον δεν έγινα αντιληπτός.
Φυσικά και δε θα γίνεται καμία επεξεργασία άμεσα από το χρήστη στον πίνακα αρχείο (Β).
Ο χρήστης εργάζεται (προσθέτει, διαγράφει και τροποποιεί εγγραφές) στο βασικό πίνακα (Α).
Όμως αφού μεταφέρουμε από τον (Α) κάποιες εγγραφές στον πίνακα (Β) και τις σημειώσουμε στον (Α) ως αρχειοθετημένες, ενδέχεται ο χρήστης να τις τροποποιήσει (στον Α).
Τότε οι εγγραφές αυτές δε θα είναι ίδιες στον (Α) και τον (Β).
Για το λόγο αυτό προτείνω την ενημέρωση.

Γιώργο, εξετάζουμε το γεγονός ότι έχουμε έναν "πινάκα-αποθήκη" δηλ. τον Β ο οποίος φιλοξενεί δεδομένα που εισάγονται
από τον χρήστη όταν εκείνος κρίνει ότι είναι έτοιμα προς αρχειοθέτηση και όχι περεταίρω επεξεργασία!
Αυτό ήταν το ζητούμενο του θέματος.

Ο πίνακας Β δεν είναι ο "κλώνος" του πίνακα Α για να καταγράφει τις οποιεσδήποτε αλλαγές του δεύτερου.
Αν οι επεξεργασίες ή διαγραφές πρέπει να περνούν και στον πίνακα Β, τότε γιατί
να μην γίνονται κατευθείαν στον πίνακα Α; Ποιος ο λόγος ύπαρξης του πίνακα Β;

Mε άλλα λόγια θα αρκούσε ένας πίνακας (A).

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

Φιλικά

Τάσος

[kapetang]

Καλημέρα

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

Υ.Γ
Γιάννη εκείνο το "καπετάν" είναι υπερβολικό.
Το σκέτο Γιώργος είναι μια χαρά.

Φιλικά/Γιώργος

[Tasos]

Σε κάναμε και 'Καπετάνιο'

[deppy]

Αγαπητοί μου,
διαβάζοντας προσεκτικά τα λόγια του Γιάννη, ομολογώ πως κάτι τέτοιο τι σκέφτηκα κι εγω.
Δηλαδή, να μην διαγράφονται οι παραγγελίες. Απλά όταν έρθει η ώρα της αποστολής, απλά να ολοκληρώνονται σαν εργασία, να μην εμφανιζονται στις ενεργές, απλα να υπάρχουν για οποιαδήποτε χρήση τους.
Μια τελευταία ερώτηση γιατι γεννιέται η απορία, πόσες εγγραφές μπορεί να δεχτεί ένας πίνακας? Για πόσο καιρό θα τον γεμίζω εγώ με εγγραφές? Να μην με απασχολεί?

[Tasos]

Καλημέρα Δέσποινα!

Στα τοπικά πρότυπα της Access 2007 υπάρχει το αρχείο Northwind 2007
Πρόκειται για ένα παραδειγματικό αρχείο διαχείρισης παραγγελιών.
Νομίζω ότι αξίζει τον κόπο να το μελετήσεις.

Όσο για το πλήθος των εγγραφών δεν πρέπει να ανησυχείς εκτός και υπερβείς το όριο των 2 GB ανά Access αρχείο
που έχει καθορίσει η Microsoft.

Φιλικά

Τάσος