2013/1/19 Kostas Oikonomou <kikono...@yahoo.gr>: > Το παράδοξο στο αρχείο, είναι ότι υπήρχαν πίνακες με πρωτεύοντα κλειδιά που > ήταν «Text [VARCHAR]», χωρίς μάλιστα να απαιτείται η αυτόματη εισαγωγή > δεδομένων! Πιθανό ο όρος για INTEGER να ισχύει για τον τρίτο ή τέταρτο > πίνακα, ή για κάτι άλλο, που δεν μπορώ να σκεφτώ (δεν είμαι πληροφορικός).
Στο αρχείο που είδα εγώ, τα πεδία με όνομα "ID" που είχαν τύπο Text δεν ήταν ορισμένα ως πρωτεύοντα κλειδιά (σε όρους γραφικού περιβάλλοντος δεν υπήρχε "κλειδάκι" στα αριστερά του ID όπως υπάρχει τώρα). Στους πίνακες που υπήρχε τέτοιο "κλειδάκι" δεν υπήρχε πρόβλημα ως προς τη λειτουργία της αντίστοιχης φόρμας. Η απαίτηση το πρωτεύον κλειδί να είναι ντε και καλά INTEGER (δηλαδή αριθμός) είναι πρόβλημα με το γραφικό περιβάλλον της Base του LibreOffice δεν είναι κάτι που ισχύει γενικά για τις βάσεις δεδομένων. Οπότε αν κάποιοι πίνακες δε δημιουργήθηκαν από το γραφικό περιβάλλον της Base αλλά π.χ., από τη γραμμή εντολών DDL της (ALTER TABLE μπλα μπλα ...) τότε μια χαρά είναι δυνατόν να υπάρχουν πρωτεύοντα κλειδιά που δεν είναι INTEGER. Ελπίζω τώρα να έγινα πιο κατανοητός. Είναι bug του GUI της Base, όχι γενική απαίτηση στις βάσεις δεδομένων, η γραμμή εντολών SQL της Base επίσης δουλεύει σωστά. > Δοκίμασα σε κάποια πρωτεύοντα κλειδιά (αυτά που είχες φτιάξει εσύ) να > καταργήσω την αυτόματη εισαγωγή δεδομένων, χωρίς να καταργηθεί το πεδίο από > πρωτεύων κλειδί. Πιθανό στους πίνακες, που αναφέρω πιο πάνω, να είχε οριστεί > αρχικά το πρωτεύων πεδίο σαν INTEGER και στη συνέχεια να το άλλαξα εγώ, για > να μπορώ να προσθέτω ότι θέλω (δεν θυμάμαι αν έγινε πράγματι κάτι τέτοιο). Αν έγινε κάτι τέτοιο αυτό θα μπορούσε να δικαιολογήσει το πρόβλημα. Το bug είναι τέτοιο ώστε όταν κάποιος αλλάξει τον τύπο του πρωτεύοντος κλειδιού (έστω "ID") π.χ., σε Text, το εικονίδιο με το κλειδάκι συνεχίζει να εμφανίζεται αλλά μόλις σώσεις τον πίνακα και κλείσεις το αντίστοιχο παράθυρο, για κάποιο μυστήριο λόγο η Base αφαιρεί την ιδιότητα του πρωτεύοντος κλειδιού (κάποιος πανέξυπνος προγραμματιστής της Sun που πέρασε βάσεις δεδομένων "νύχτα" ευθύνεται γι αυτό μάλλον :P) Οπότε μπορεί να άλλαξες τον τύπο του πεδίου, δεν είδες να αλλάζει τίποτα (συνέχιζε να δείχνει κλειδάκι) και μετά το έκλεισες και αυτό πίσω από την πλάτη σου αφαίρεσε την ιδιότητα "πρωτεύον κλειδί" από το ID το οποίο το κατάλαβες μόνο από τη συνέπεια που είχε (το ότι κλείδωσαν οι αντίστοιχες φόρμες). Μη γνωρίζοντας τώρα το τι μπορεί να ευθύνεται για το κλείδωμα των φορμών πού να πάει ο νους σου ότι μπορεί να φταίει το άλλαγμα του τύπου ενός πεδίου το οποίο μάλιστα δεν είδες να έχει και ορατές συνέπειες. Φαντάζομαι θα έχεις αντιμετωπίσει αρκετά τέτοια περιστατικά στην ιατρική όπου μια φαινομενικά εντελώς αθώα αλλαγή ή παρέμβαση, που μπορεί μάλιστα βραχυπρόθεσμα να μην έχει καν ορατά ή μετρήσιμα αποτελέσματα, μακροπρόθεσμα μπορεί να έχει σημαντικότατες συνέπειες. > Τέλος, για να μην έχω πρόβλημα, μετέτρεψα όλα τα πρωτεύοντα κλειδιά σε > INTEGER με αυτόματη εισαγωγή δεδομένων, και πρόσθεσα ένα άλλο πεδίο, με > τίτλο patient, όπου θα βάζω ένα μοναδικό κωδικό για τον κάθε ασθενή. Στη > συνέχεια δοκίμασα να ορίσω σχέσεις μεταξύ των πινάκων, με το πεδίο patient > που θα είναι μοναδικό για κάθε ασθενή, χωρίς επιτυχία. Βγαίνει μήνυμα > λάθους, στα αγγλικά, που απ' ότι κατάλαβα λέει ότι το πεδίο patient, πρέπει > να είναι πρωτεύων κλειδί ή να μην έχει διπλές τιμές στον πίνακα (πχ δυο > τιμές με, ας πούμε, 32). Το πεδίο patient είναι επί του παρόντος «Text > [VARCHAR]». Πως θα ελέγχει η Base ότι δεν υπάρχουν διπλές τιμές, έτσι που να > με αφήσει να ορίσω τις σχέσεις; Με την αυτόματη τιμή στο Id, το πρωτεύων > κλειδί, δεν μπορώ να το χρησιμοποιήσω για τη δημιουργία σχέσης μεταξύ των > πινάκων. > > Ελπίζω να μην σας μπέρδεψα πολύ. Καθόλου δε μας μπέρδεψες :) Καταρχήν η αυτόματη τιμή στο ID σε τι σε εμποδίζει από το να το χρησιμοποιήσεις για τη δημιουργία σχέσης μεταξύ πινάκων; Ίσα-ίσα που δε χρειάζεται να εφευρίσκεις μοναδικούς κωδικούς για κάθε ασθενή π.χ., και να σκέφτεσαι αν κάποιο αριθμό τον έχεις χρησιμοποιήσει ξανά ή όχι. Το να μην έχει διπλοεγγραφές ένα πεδίο Text δεν είναι πρόβλημα η base να το ελέγξει. Π.χ., αν ξέρει ότι ως τώρα δεν υπάρχουν διπλοεγγραφές αρκεί να ελέγχει κάθε νέα καταχώρηση ότι δεν ταυτίζεται με μια από τις υπάρχουσες. Αυτό μπορεί να γίνει συγκρίνοντας π.χ., χαρακτήρα προς χαρακτήρα (φυσικά αυτό είναι πολύ λιγότερο αποδοτικό από το να συγκρίνεις ακεραίους συνήθως και γι αυτό ο κόσμος προτιμά τα πεδία τύπου ID να είναι τύπου INTEGER). Οπότε εν κατακλείδι, το σωστό και πρακτικό είναι να κάνεις σχέσεις μεταξύ πινάκων με βάση το πρωτεύον κλειδί μόνο. Το ότι το κλειδί αυτό θα είναι αριθμός (και μάλιστα με αυτόματη αύξηση) δε θα πρέπει να σε αποθαρρύνει με κάποιο τρόπο από το να το χρησιμοποιήσεις. Χαιρετισμούς, Παντελής -- Ubuntu-gr mailing list Ubuntu-gr@lists.ubuntu.com If you do not want to receive any more messages from the ubuntu-gr mailing list, please follow this link and choose unsubscribe: https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr
