Ερώτηση MS Access

[pt3]

Εχω μια βάση δεδομένων Access με 2 Πϊνακες. Ο πρώτος ονομάζεται προμηθευτές και περιέχει τα στοιχεία τους με πεδία όπως ΑΦΜ, Ονομασία, Δ/νση, Τηλ κλπ. Ο 2ος περιέχει τιμολόγια που έχουν εκδοθεί από τους προμηθευτές και έχει τα πεδία ΑΦΜ, αρ τιμολ, ημερομηνία, ποσό. Οι δύο πίνακες συνδέονται με το πεδίο ΑΦΜ.

Αυτό που θέλω είναι να φτιάξω μια φόρμα ενημέρωσης του 2ου πίνακα με τα εξής στοιχεία
1. Πεδίο εισόδου ΑΦΜ, όπου θα ελεγχεται αν υπάρχει το ΑΦΜ στον 1ο πίνακα ή εναλακτικά μέσω λίστας να σου επιτρέπει να επιλέξεις μονο ΑΦΜ που υπάρχουν.
2,3,4 Πεδία στα οποία δεν θα επιτρέπεται εγγραφή και θα παρουσιάζονται τα στοιχεία του προμηθευτή (Ονομασία Δ.νση κλπ) του οποίου το ΑΦΜ επιλέχθηκε.
5,6,7 Πεδία που θα καταχωρώ τα υπόλοιπα στοιχεία του Πίνακα.

Μπορεί κανείς να βοηθήσει για το πώς μπορουν να φτιαχθούν τα πρώτα 4 πεδία. Με ποιές ιδιότητες δηλαδή τα διάφορα Text box θα έχουν τέτοια λειτουργία? Η βάση Northwind που έχει σαν υπόδειγμα η MS έχει τέτοιες δυνατότητες αλλα δεν μπορώ να δω πως υλοποιούνται.

Γνωρίζει κανείς κάποιο βιβλίο ή ακόμα καλύτερα κάποιο site με τέτοιου τύπου περιέχόμενο? γιατι τα περισσότερα που βρίσκω σχετικά με Access αναφέρονται στα πολύ στοιχειώδη.

[gitane]

Ο πιο απλός τρόπος να απαγορεύσεις εγγραφή, είναι να βάλεις την ιδιότητα "Locked" του αντίστοιχου textBox σε "Yes" - αν το textBox είναι συνδεδεμένο (bound) στον πίνακα.

Πιο περίπλοκος τρόπος είναι να έχεις ελεύθερα textBox , τα οποία γεμίζεις προγραμματιστικά με κώδικα που τρέχει σε αλλαγή επιλεγμένης εγγραφής - πιο ευαίσθητο σε "σκασίματα", αλλά με 100% προστασία των στοιχείων του πίνακα προμηθευτών.

[yiapap]

1. Combo box bound στο πεδίο ΑΦΜ του 2ου πίνακα και Datasource SELECT AFMFrom Προμηθευτές SORT BY ΑΦΜ
+ ιδιότητα Limit to list = Yes
2,3,4 Αυτό που λέει ο gitane

Μπορείς επίσης να φτάξεις φόρμα υποφόρμα. Η κύρια φόρμα είναι οι προμηθευτές η υποφόρμα είναι τα τιμολόγια. Δοκίμασέ το γιατί νομίζω ότι είναι η καλύτερη λύση. Οι άλλες λύσεις θα απαιτήσουν και κώδικα (π.χ. αν προσθέσεις έναν προμηθευτή πρέπει να κάνεις Requery το Combobox για να δεις το νέο ΑΦΜ).

[mpetou]

καταρχην η επιλογη ΑΦΜ για PK ειναι λαθος οπως επισης και FK ...
αυτο που ζητας γινετε με foreign keys στις κανονικες σχεσιακες βασεις πολυ απλα.
απορω ενω υπαρχουνε public domain embedded dbs (sqlite) αλλα και open src γιατι ασχολείστε με access..

[yiapap]

Γιατί το ΑΦΜ είναι λάθος; Επειδή είναι text πεδίο;

[MichaelSE]

Γιατί το ΑΦΜ είναι λάθος; Επειδή είναι text πεδίο;

Γενικά είναι λάθος πρακτική να βάζουμε πεδία που έχουν ουσιαστική σημασία ως PK (και ως FK). Τα πεδία PK πρέπει να είναι χωρίς σημασία. Παλιότερα ένας απλός ΑΑ ενώ τώρα συνηθίζεται να είναι GUID, που έχει πολλά πλεονεκτήματα.

Αυτό συμβαίνει γιατί τα πεδία με ουσιαστική σημασία μπορεί να αλλάξουν (για το ΑΦΜ μπορεί π.χ. να έχει πληκτρολογηθεί λάθος και να χρειαστεί να αλλάξει). Αν είναι PK ή FK δεν μπορεί να αλλάξει και πρέπει να γίνουν update όλα τα references σε αυτό.

[yiapap]

Αυτό συμβαίνει γιατί τα πεδία με ουσιαστική σημασία μπορεί να αλλάξουν (για το ΑΦΜ μπορεί π.χ. να έχει πληκτρολογηθεί λάθος και να χρειαστεί να αλλάξει). Αν είναι PK ή FK δεν μπορεί να αλλάξει και πρέπει να γίνουν update όλα τα references σε αυτό.

Στην Access μπορεί να αλλάξει και η αλλαγή θα περάσει (cascading update) σε όλους τους πίνακες που χρησιμοποιούν το πεδίο ως FK
Επίσης το ΑΦΜ δύσκολα μπορεί να πληκτρολογηθεί λάθος με δεδομένο ότι υπάρχει αλγόριθμος ελέγχου εγκυρότητας ο οποίος θα πιάσει το λαθάκι.

[mpetou]

με το κανεις PΚ/FK το ΑΦΜ μπλεκεις τη λειτουργια με τα δεδομενα της βασης.
επισης text πεδια δεν κανουνε για FK/PK δεν μπορει να γινει αποδοτικο indexing κτλπ
Το καλύτερο ειναι 1 surrogate key

[MichaelSE]

Στην Access μπορεί να αλλάξει και η αλλαγή θα περάσει (cascading update) σε όλους τους πίνακες που χρησιμοποιούν το πεδίο ως FK
Επίσης το ΑΦΜ δύσκολα μπορεί να πληκτρολογηθεί λάθος με δεδομένο ότι υπάρχει αλγόριθμος ελέγχου εγκυρότητας ο οποίος θα πιάσει το λαθάκι.

Γενικώς, με τα PKs με νόημα (γενικά μιλώντας - όχι μόνο για το ΑΦΜ) υπάρχουν πολλά προβλήματα, πέρα από αυτά που ανέφερα, και προβλήματα που δεν μπορείς να τα προβλέψεις στην αρχή. Π.χ. τι θα γίνει αν ο πελάτης δεν έχει ΑΦΜ (πελάτης λιανικής π.χ). Ή αν έστω θέλεις να καταχωρήσεις τον προμηθευτή (που έχει οπωσδήποτε ΑΦΜ) προσωρινά με το ΑΦΜ αναφοράς για να το συμπληρώσεις αργότερα με το σωστο; Ή αν αλλάξει ο αλγόριθμος για τους ΑΦΜ και επαναχρησιμοποιηθεί σε κάποιον άλλον μετά το κλείσιμο π.χ. μίας εταιρείας. Ή να προστεθεί ένα ψηφίο μπροστά σε όλους (όπως έγινε σχετικά πρόσφατα); Ή γενικώς σε 5 χρόνια π.χ. να αλλάξει τελείως το σύστημα με το ΑΦΜ και ενοποιηθούν π.χ. όλοι οι αριθμοί; (ΑΦΜ - ΑΜΚΑ - ΑΤ και ό,τι άλλο μπορεί αν φανταστεί ο καθένας).

Για όλα αυτά τα θέματα είναι καλό να διαλέγεις PK χωρίς σημασία. Εκεί δεν έχεις να σκεφτείς τίποτα. Το μόνο μειονέκτημα είναι λίγο παραπάνω χώρος στη DB. Νομίζω μικρό τίμημα σε σχέση με αυτά που κερδίζεις.

[yiapap]

με το κανεις PΚ/FK το ΑΦΜ μπλεκεις τη δομη με τα δεδομενα της βασης

Στη θεωρία Βάσεων Δεδομένων πάντως δεν θυμάμαι τέτοιο directive. Βέβαια εγώ είμαι αρχαίος και μπορεί κάτι να έχει αλλάξει. Υπάρχει κάποιο ακαδημαϊκό reference για το παραπάνω;

[mpetou]

δες τα βιβλια του joe celko
και αυτο του 99 το λεει και τα ποιο καινουργια
επισης λεει οτι σε περιπτωση που δεν εχουμε να κανουμε με κατανεμημενη βαση
η καλυτερη επιλογη ειναι auto increment / serial κτλπ

[yiapap]

Γενικώς, με τα PKs με νόημα (γενικά μιλώντας - όχι μόνο για το ΑΦΜ) υπάρχουν πολλά προβλήματα, πέρα από αυτά που ανέφερα, και προβλήματα που δεν μπορείς να τα προβλέψεις στην αρχή. Π.χ. τι θα γίνει αν ο πελάτης δεν έχει ΑΦΜ (πελάτης λιανικής π.χ). Ή αν έστω θέλεις να καταχωρήσεις τον προμηθευτή (που έχει οπωσδήποτε ΑΦΜ) προσωρινά με το ΑΦΜ αναφοράς για να το συμπληρώσεις αργότερα με το σωστο; Ή αν αλλάξει ο αλγόριθμος για τους ΑΦΜ και επαναχρησιμοποιηθεί σε κάποιον άλλον μετά το κλείσιμο π.χ. μίας εταιρείας. Ή να προστεθεί ένα ψηφίο μπροστά σε όλους (όπως έγινε σχετικά πρόσφατα); Ή γενικώς σε 5 χρόνια π.χ. να αλλάξει τελείως το σύστημα με το ΑΦΜ και ενοποιηθούν π.χ. όλοι οι αριθμοί; (ΑΦΜ - ΑΜΚΑ - ΑΤ και ό,τι άλλο μπορεί αν φανταστεί ο καθένας).

Για όλα αυτά τα θέματα είναι καλό να διαλέγεις PK χωρίς σημασία. Εκεί δεν έχεις να σκεφτείς τίποτα. Το μόνο μειονέκτημα είναι λίγο παραπάνω χώρος στη DB. Νομίζω μικρό τίμημα σε σχέση με αυτά που κερδίζεις.

Στον πελάτη λιανικής δίνεις ένα εικονικό ΑΦΜ (0000000000). Τις υπόλοιπες ενημερώσεις που λες τις κάνεις κανονικά όπως σε οποιοδήποτε πεδίο με το πρόσθετο πλεονέκτημα που ανάφερα ότι αν χρησιμοποιείς το ΑΦΜ ως κλειδί κάνεις την ενημέρωση στον βασικό πίνακα και αυτή αυτόματα ενημερώνει όλους τους συνδεδεμένους.

Καταλαβαίνω τη λογική και δεν λέω ότι διαφωνώ απαραίτητα, απλά περιγράφω την άλλη όψη του νομίσματος

[mpetou]

θα το συζητουσαμε για κατανεμημενη βαση αλλα γι αυτη την περιπτωση
δεν σωστο ασε που το text key ειναι αντιαποδοτικο

[MichaelSE]

Στη θεωρία Βάσεων Δεδομένων πάντως δεν θυμάμαι τέτοιο directive. Βέβαια εγώ είμαι αρχαίος και μπορεί κάτι να έχει αλλάξει. Υπάρχει κάποιο ακαδημαϊκό reference για το παραπάνω;

Κι εγώ δεν θυμάμαι τέτοιο directive στη θεωρία Βάσεων Δεδομένων. Όλα αυτά που σου είπα είναι από γενικά guidelines που προκύπτουν από προβλήματα στη βάση όταν είναι σχεδιασμένη με αυτόν τον τρόπο που αναφέρεις. Μάλιστα παλιότερα υπήρχε όντως αυτή η πρακτική. Δες π.χ. εδώ.

Στον πελάτη λιανικής δίνεις ένα εικονικό ΑΦΜ (0000000000). Τις υπόλοιπες ενημερώσεις που λες τις κάνεις κανονικά όπως σε οποιοδήποτε πεδίο με το πρόσθετο πλεονέκτημα που ανάφερα ότι αν χρησιμοποιείς το ΑΦΜ ως κλειδί κάνεις την ενημέρωση στον βασικό πίνακα και αυτή αυτόματα ενημερώνει όλους τους συνδεδεμένους.

Καταλαβαίνω τη λογική και δεν λέω ότι διαφωνώ απαραίτητα, απλά περιγράφω την άλλη όψη του νομίσματος

Συμφωνώ, αλλά αν π.χ. ο ίδιος πελάτης έρθει την άλλη μέρα και σου ζητήσει τιμολόγιο αντί απόδειξη; Και σου λέω, φυσικά υπάρχουν λύσεις για όλα, software είναι, αλλά γιατί να μπεις σε τέτοιες διαδικασίες και να μην το φτιάξεις έτσι από την αρχή; Το ID χωρίς νόημα δεν θα αλλάξει ποτέ εγγυημένα, άρα δεν θα μπεις ούτε καν στη διαδικασία του cascading update.

........Auto merged post: MichaelSE πρόσθεσε 82 λεπτά και 59 δευτερόλεπτα αργότερα ........

θα το συζητουσαμε για κατανεμημενη βαση αλλα γι αυτη την περιπτωση
δεν σωστο ασε που το text key ειναι αντιαποδοτικο

Θεωρώ ότι ακόμα και σε κατανεμημένη βάση δεν είναι καλή πρακτική πεδιά με business meaning ως PKs. Σε εκείνη την περίπτωση το καλύτερο, κατά την άποψή μου είναι GUID που λύνει και τα προβλήματα του auto increment σε distributed dbs. Βέβαια ακόμα και σε τοπική βάση πιστεύω ότι το GUID λύνει προβλήματα όπως migrations και γενικότερα μεταφορές δεδομένων. Απλά πιάνει λίγο παραπάνω χώρο. Και χρειάζεται κάποια παραπάνω διαχείριση σε βάσεις που δεν το υποστηρίζουν απευθείας ακόμα.

[mpetou]

http://databases.aspfaq.com/database...imary-key.html