Γεια σας. Δημιουργώ μια εφαρμογή σε Visual .NET με την οποία θέλω να διαχειρίζομαι την βάση δεδομένων που έχω στον sql server. Το βασικό κλειδί ID του πίνακα είναι με αυτόματη αρίθμηση. Έχω φτιάξει μια φόρμα με ένα DataGridView όπου εμφανίζει τις εγγραφές του πίνακα. 3 buttons (btnNew,btnCancel,btnSave) και ένα TextBox που εμφανίζει τo ID. 

   Πατώντας το btnNew, εμφανίζεται στο TextBox το επόμενο διαθέσιμο ID με την χρήση της BindingSource.AddNew().Πατώντας το κουμπί btnCancel ακυρώνω την διαδικασία “BindingSource.CancelEdit()DataSet.RejectChanges().”

   Το πρόβλημα είναι ότι αν ξαναπατήσω το κουμπί btnNew το ID δεν είναι το προηγουμενο που ειχε εμφανιστεί αλλά αυξημένο κατά ένα. Θα ηθέλα να μου πείτε πως μπόρω να πάρω το επόμενο διαθέσιμο ID το οποίο θα είναι ίδιο μετά από αρκετά(btnNew,btnCancel) και θα αυξηθεί μόνο όταν γίνει καταχώριση στη βάση(btnSave).Ελπίζω να μην σας μπέρδεψα!

 

Το ID που σου δίνει το dataset όταν προσθέτεις μια εγγραφή σε αυτό (στο dataset πριν το στείλεις στη βάση) είναι εικονικό και βασίζεται στις εγγραφές που έχει ήδη το dataset μέσα του (χονδρικά το μικρότερο νούμερο που δεν έχει χρησιμοποιηθεί). Όταν στείλεις το dataset στη βάση (πιθανόν με ένα update κάποιου dataadapter), τότε στο insert που θα γίνει η βάση θα αποδώσει το κανονικό ID το οποίο κατά πάσα πιθανότητα θα διαφέρει από αυτό που πήρε η εγγραφή όταν μπήκε στο dataset. Όταν γίνει το update με τον dataadapter, αυτός θα φροντίσει ώστε να ενημερώσει το προσωρινό ID που είχε δώσει με αυτό που τελικά έδωσε η βάση.

Πατέντες για να ελέγχεις το τι νούμερο θα σου δώσει το dataset πριν το βάλεις στη βάση μπορούν να γίνουν διάφορες (όπως να μην είναι autoincrement το πεδίο και να ελέγχεις μόνος σου την sql που κάνει το insert), αλλά αυτό που πρέπει να προσέχεις είναι ότι το RowID πρέπει να είναι ένα νούμερο που η μόνη του χρήση είναι ο προσδιορισμός με μοναδικό τρόπο μίας εγγραφής. Δεν πρέπει να έχει καμία άλλη σημασία για το business logic της εφαρμογής και στο 99% των περιπτώσεων δεν θα πρέπει καν να εμφανίζεται στους χρήστες. Το λάθος που γίνεται συχνά είναι ότι οι προγραμματιστές συγχέουν το RowID με το πεδίο "Κωδικός" που αναφέρεται στο business logic επειδή πολλές φορές φορές συμπίπτουν.

Σωστότερο όμως είναι, αν υπάρχει ανάγκη για πεδίο "Κωδικός", αυτό να υλοποιείται σε διαφορετικό πεδίο και όχι στο autoincrement RowID. Έτσι, θα μπορείς αργότερα να υλοποιήσεις αλλαγές στο business logic της εφαρμογής που αφορά το πεδίο "κωδικός" χωρίς να χρειάζεται να κάνεις αλλαγές στο RowID το οποίο κάνει πολύ συγκεκριμένη δουλειά στη βάση δεδομένων. Για παράδειγμα, πολλές φορές ο πελάτης ζητάει εκ των υστέρων να αλλάξουν κάποιοι κωδικοί προϊόντων. Αν έχεις ταυτίσει τον "κωδικό" με το RowID μπορεί να έρθεις αντιμέτωπος με πολλά προβλήματα, ιδιαίτερα σε μια έντονα σχεσιακή βάση δεδομένων. Αν όμως το πεδίο "κωδικός" είναι διαφορετικό από το RowID, τότε μπορείς να αφήσεις τους χρήστες να το αλλάζουν κατά βούληση.

---

Χρήστος Γεωργακόπουλος

Τον επόμενο διαθέσιμο αριθμό(auto increment) που δίνει η βάση δεν γίνεται να τον πάρω χωρίς να τον χρησιμοποιήσω;(μόνο ανάγνωση).Να διαβάσω το ID της τελευταίας εγγραφής και να προσθέσω 1 δεν είναι ότι σωστότερο γιατί αν η τελευταία εγγραφή έχει διαγραφεί το auto increment ID θα είναι 2 αριθμούς αυξημένο και όχι 1. Καμία ιδέα πως μπορώ να εμφανίσω το σωστό auto increment ID?

Όπως σου είπε και ο cgeo, δεν υπάρχει τρόπος για να κάνεις κάτι τέτοιο, παρά μόνο αν υλοποιήσεις εσύ τον μηχανισμό παραγωγής των IDs, πράγμα όχι και τόσο εύκολο. Πάντως, έχε υπόψην σου ότι συνήθως τη βάση την χρησιμοποιούν πολλοί χρήστες πράγμα που σημαίνει ότι ακόμα κι αν μπορούσες απλά να διαβάσεις το επόμενο ID, μέχρι να το χρησιμοποιήσεις εσύ, μπορεί ήδη να έχει χρησιμοποιηθεί από κάποιον άλλον. Επίσης, σημείωσε σε αυτά που σου είπε ο cgeo ότι το auto increment ID δεν είναι για να το χρησιμοποιούμε εμείς.

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

---

Vir prudens non contra ventum mingit

Σας ευχαριστώ παιδιά για την βοήθεια. Αυτό που θέλω να κάνω είναι να εμφανίζω τον κάθε κωδικό ID των πινάκων της βάσης πριν το insert ώστε ο χρήστης να γνωρίζει εκ των προτέρων ποιο ID θα χρησιμοποιήσει. Όταν δηλαδή μπει στην φόρμα εισαγωγής νέου προϊόντος να του είναι γνωστό το ID προϊόντος. Από αυτά που μου είπατε η λύση είναι να εμφανίζω το ID μετά την εισαγωγή. Όπως ολόσωστα είπε ο cgeo ίσως προκύψει η ανάγκη για αλλαγή του κωδικού προϊόντος όπου με την auto increment επιλογή που έχω επιλέξει είναι αδύνατο να πραγματοποιηθεί.



Ένας μηχανισμός παραγωγής ID πώς θα μπορούσε να υλοποιηθεί; Ίσως ένας extra πίνακας στη βάση που θα κράταγε όλα τα επόμενα διαθέσιμα ID; Με αυτή την υλοποίηση θα έπρεπε να ελέγχεται το επόμενο διαθέσιμο ID με κάποιο ID που έχει δώσει ο πελάτης. Φαίνεται περίπλοκο και εγκυμονεί κινδύνους.To auto increment είναι απλό αλλά έχει περιορισμούς. Εσείς ποια μέθοδο θα χρησιμοποιούσατε;

Πριν να φτάσεις στον δικό σου μηχανισμό auto increment (που δεν είναι πολύ εύκολο να υλοποιηθεί), μπορείς να μας πεις για ποιόν λόγο θα πρέπει να γνωρίζει ο χρήστης το ID της εγγραφής που πρόκειται να μπει; Μπορείς να κάνεις αυτό που είπε ο cgeo, να βάλεις ένα δεύτερο πεδίο που θα παίξει το ρόλο του κλειδιού (ονομάζεται surrogate key) το οποίο θα το θέσεις ως unique και θα αφήσεις τον χρήστη να βάζει εκεί ό,τι τιμή θέλει, αρκεί να μην υπάρχει ήδη αυτή η τιμή σε προηγούμενο κλειδί.

---

Vir prudens non contra ventum mingit

Για λόγους εμφάνισης και πρακτικότητας. Σε μια φόρμα εισαγωγής στοιχείων θα ήταν ομορφότερο και πρακτικότερο ο χρήστης να βλέπει τον κωδικό που θα αποδώσει σε ένα προϊόν και όχι να περιμένει να του αποδοθεί ο κωδικός μετά την εισαγωγή.(Να νιώθει κυρίαρχος της εφαρμογής). Και με το να μην εμφανίζεται στην φόρμα εισαγωγής και να εμφανίζεται στις φόρμες Τροποποίησης και Διαγραφής, Η εφαρμογή δεν θα έχει συνοχή.

Άρα λοιπόν κάτι τέτοιο μπορεί άνετα να υλοποιηθεί με το surrogate key. Εξάλλου, αν πρόκειται να κάνεις τροποποίηση του κλειδιού, είναι εξαιρετικά δύσκολο να το κάνεις με auto-increment πεδίο. Με το surrogate key λύνεις όλα τα προβλήματα και ο χρήστης αισθάνεται ακόμα πιο κυρίαρχος της εφαρμογής καθώς μπορεί να δώσει ο,τι τιμή θέλει ως κλειδί. Μπορεί ακόμη-ακόμη να είναι και αλφαριθμητικό.

 

---

Vir prudens non contra ventum mingit

Σωστός αλλά αν έχει τέτοια ελευθερία μπορεί να τα θαλασσώσει. Στην περίπτωση του surrogate key θα πρέπει να έρχεται πακέτο και ένας μηχανισμός προαιρετικού auto ID γιατί αν ο χρήστης μπαίνει σε όλη την διαδικασία να βρει ποιος κωδικός είναι ελεύθερος ή του πετάγονται συχνά πυκνά μηνύματα του στυλ «Ο κωδικός που δώσατε χρησιμοποιείται » μόνο κυρίαρχος δεν θα νιώθει.

Ναι, δεν θα πρέπει να βάζει ό,τι του κατέβει... Συνήθως, υπάρχει κάποιο σχετικό πεδίο που δίνει μοναδικότητα σε business-logic level, πέρα από την database... Αν θα είναι τιμολόγια, θα είναι ο αριθμός τιμολογίου, αν θα είναι αυτοκίνητα, θα είναι ο αριθμός κυκλοφορίας, κλπ. Στη δική σου περίπτωση, δεν υπάρχει κάποιο τέτοιο προσδιοριστικό;

---

Vir prudens non contra ventum mingit

Σε μερικά από τα προϊόντα υπάρχουν αυτά τα προσδιοριστικά αλλά σε άλλα όχι.

Όλα τα προϊόντα είναι σε ένα πίνακα και κατηγοριοποιούνται βάσει των τιμών δύο πεδιών του πίνακα.Πολύ καλή πρακτική για τους κωδικούς αυτή, ειδικά για γρήγορες αναζητήσεις.

Δηλαδή αυτά τα δύο πεδία, προσδίδουν μοναδικότητα;

---

Vir prudens non contra ventum mingit

Όχι καμία σχεση. Μοναδικότητα προσδίδει το πεδίο id increment. Σας ευχαριστώ παιδιά για την βοήθεια.

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

Ωστόσο έχεις διάφορα θέματα για να προσέξεις. Μερικά από αυτά είναι: Σε ένα πολυχρηστικό περιβάλλον ενδέχεται και άλλοι να έχουν ζητήσει να μάθουν ποιά είναι η τελευταία τιμή ώστε να χρησιμοποιήσουν την επόμενη. Επίσης, τι θα γίνεται αν ένας χρήστης ακυρώσει την εισαγωγή; Θα πρέπει η εισαγωγή του προϊόντος μαζί με το update της εγγραφής που δείχνει στο τελευταίο ID να γίνεται σε ένα κοινό transaction. Ο πίνακας αυτός δε, μπορεί να αποτελέσει ένα hot-spot για την εφαρμογή σου, δηλαδή λόγω του locking που θα συμβαίνει σε αυτόν, να φρενάρει ολόκληρη την εφαρμογή.

Γι αυτό θεωρώ ότι είναι προτιμότερο να ορίσεις ένα surrogate key και να αφήσεις τους χρήστες να βάζουν ό,τι κλειδί θέλουν. Εξάλλου μπορείς να τους ορίσεις κάποιο guideline ώστε να κωδικοποιήσουν τα κλειδιά με τέτοιο τρόπο που να σχετίζονται με το προϊόν.

---

Vir prudens non contra ventum mingit

Νομίζω ότι ο Μάνος έχει απόλυτο δίκιο σέ όσα σου λέει

---

Ιωάννης Μανουσάκης