Καλησπέρα σας.

 Είμαι νέος εδώ πέρα. Καταρχήν συγχαρητήρια για την Κοινότητα σας.

'Εχω κολήσει κάπου σε μια εφαρμογή που προσπαθώ να φτιάξω και θα ήθελα τα φώτα σας.

Εχω ενα πίνακα και εκει μέσα μαζεύω κάποιες εγγραφές. το Πεδίο Α/Α το καταχωρώ απο την φόρμα με δυναμικό τρόπο. Var = var +1.

Ολες οι εγγραφές με το που καταχωρούνται εμφανίζονται στο κάτω μέρος της φόρμας σε ένα Datagrid.

Οταν πάω να διαγράψω μια εγγραφή τότε χάνω την σείρα των Α/Α με αποτέλεσμα στην επόμενη νέα εγγραφή να μην κρατίεται η σειρα.

 Να τονίσω ότι ο έλεγχος στα objects γίνεται μέσω κώδικα και όχι με τα έτοιμα που δίνει το κάθε object σε Design mode.

p.x

a/a          name

1              vagelis

2             giorgos

3             kostis

4           marika

αν διαγραψω τον κωστή

τοτε έχω

1           vagelis

2          giorgos

4          marika

Θα ήθελα να είχα....

1               vagelis

2              giorgos

3              marika

Μπορεί κάποιος να με βοηθήσει με ποιον τρόπο θα μπορέσω σε κάθε διαγραφή να κάνω resorting στο Α/Α ? Κολάω στο Query build..... :(

 Σας Ευχαριστώ.

Αν θελεις να κρατας στην βαση τον αριθμο που εχει καθε εγγραφη και ταυτοχρονα αυτος ο αριθμος να ειναι και το πρωτευων κλειδι τοτε εχεις δημιουργησει για τον εαυτο σου εναν πονοκεφαλο. Και πολυ μεγαλο μαλιστα.

θα μπορουσαμε να συζητησουμε το θεμα για την αυτοματη αριθμηση αλλα αν ειναι και πρωτευων κλειδι στον πινακα θα σου ελεγα να το σταματησεις εδω, να επιστρεψεις στην αναλυση σου και να το αποφυγεις.

 Τα πρωτευων κλειδια δεν αλλαζουν, σε περιπτωση που εχεις και αλλους συσχετιζομενους πινακες στην βαση θα δημιουργησεις μπελαδες με καθε αλλαγη πρωτευων κλειδιου. Επισης δινεις την τιμη απο την εφαρμογη. Σιγουρα δεν θα την χρησιμοποιεισουν δυο χρηστες την εφαρμογη; Τι θα γινει εκει;

Αν τωρα δεν χρησιμοποεις το Α/α σαν πρωτευων κλειδι και αφηνεις την βαση ας πουμε να δινει το δικο της. Αν το θελεις στην εφαρμογη σου για να δειχνεις απλα σε ενα grid το συνολο των εγγραφων δεν χρειαζεται να το αποθηκευσης στην βαση. Μπορεις να κανεις ενα iteration στην λιστα με τα ονοματα και διπλα σε καθε ονομα να βαλεις την τιμη του index συν ενα. Ετσι θα εχεις παντα μια σωστη αριθμηση ανεξαρτητα το πως θα ειναι το ερωτημα σου στην βαση. Για παραδειγμα φερε μου τους πελατες που ξεκινουν απο καπα. Τι θα του εφερνες 56, 67, 79 ; Γιατι αν καταχωρησεις την αριθμηση στην βαση αυτο θα του εφερνες. Αν ομως το εκανες δυναμικα θα εδειχνες στο grid σου 1,2,3. 

Οποτε οπως καταλαβαινεις ειμαι αντιθετος στην αποθηκευση του Α/A στην βαση και αντιθετος να αλλαζεις τα κλειδια.  

Καταρχήν συμφωνώ απόλυτα με τον προλαλήσαντα.

Μια άλλη εναλλακτική είναι να μην πεις το πεδία Α/Α αλλά κωδικό και να το σώνεις στην βάση σου σαν υποχρεωτικό πεδίο αλλά όχι φυσικά πρωτεύον κλειδί.  Θεωρώ ότι το πρωτεύον κλειδί πρέπει να είναι πάντα GUID αλλά αυτό είναι άλλη συζήτησης.

Θα μπορούσες να έχεις ένα κουμπί την φόρμα σου ‘Επαναρίθμηση΄ στο οποίο θα κάνεις loop τις εγγραφές και θα αλλάζεις τον κωδικό αλλά μόνο με την συγκατάθεση του χρήστη.

Επίσης στο delete μπορείς να τον ρωτάς αν θέλει και να κάνεις επαναρίθμηση των κωδικών  και αν ναι τότε αφού κάνεις το delete να κάνεις επαναρίθμηση.

Όλα αυτά εξαρτώνται από το αν έχει business νόημα o κωδικός.  Αν δεν έχει τότε η παραπάνω λύση δεν είναι ενδεδειγμένη

manosB:

Θεωρώ ότι το πρωτεύον κλειδί πρέπει να είναι πάντα GUID αλλά αυτό είναι άλλη συζήτησης.

Η επιλογή του guid data type as primary key πρέπει να γίνεται με σύνεση καθώς όπως έχω εξηγήσει εδώ http://www.sqlschool.gr/blog/uniqueidentifier-data-type-as-table-primary-key-or-clustered-index-56.aspx  δημιουργεί συνεχές fragmentation. Επίσης ακόμα και όταν γίνεται χρήση της newsequentialid είναι κακή πρακτική να είναι clustered index καθώς το datatype αυτό είναι 16 bytes και όταν έχω nonclustered indexes αυτό συμμετέχει μέσα στη δομή αυτών.

Τώρα σχετικά με το θέμα. Η απόλυτη αύξουσα αρίθμηση πρακτικά δεν μπορεί να υπάρξει. Αν πάντως κάτι τέτοιο είναι επιθυμητό να γίνει θα πρέπει να γίνει σε ένα άλλο πεδίο που δεν είναι primary key. Από εκεί και πέρα το identity όπως και τα sequence δεν σου εγγυούνται ότι δεν θα υπάρχουν gaps. Θα πρέπει να βρεις την τεχνική που σε βολεύει για αυτό συνήθως είναι με ένα πίνακα που κρατάει την τιμή αυτή και θα πρέπει να κοιτάς και να ενημερώνεις ανάλογα. Αν πάντως θέλεις γρήγορα να ενημερώνεις το πεδίο αυτό μπορείς να το κάνεις με το παρακάτω script . Έστω ότι εχω τον πίνακα Τ και σε αυτό το πεδίο είναι το ΑΑ

declare @I int = 0

update T set @I=AA=@I+1

Επειδή είμαι σε διακοπές δεν μπορώ να το αναλύσω περισσσότερο αλλά πιστεύω ότι έπιασες το νόημα

Αντώνη θα συνεχισω απο το τελευταιο σου post και θα ηθελα σε παρακαλω να μου δωσεις μια απαντηση αν γνωριζεις. Στα Azure Mobile Services η Microsoft αλλαξε το id του καθε πινακα απο int σε string. Αν μαλιστα δεν δωσεις τιμη στο id σου περναει αυτοματα guid. Αν και εχει εξηγησει τους λογους για τους οποιους το εκανε θεωρω πως θα επρεπε να δινει την επιλογη στον χρηστη. Αν χρισημοποιησεις Mobile Service σαν .Net Backend ισως να εχεις την επιλογη να το ορισεις εσυ σαν int αλλα αν εχεις node.js τοτε το περνεις ετοιμο. Μου φαινεται λιγο περιεργη αυτη η προσεγγιση. Αραγε δεν γνωριζουν τα μειονεκτηματα μιας τετοιας προσεγγισης; Δεν γνωριζουν οτι το string σαν id datatype ειναι για μερικα σεναρια μονο; πως το προτεινουν σαν καθολικη λυση.

 και φθανω στο ερωτημα. μηπως με τον Sql Azure εχουν αλλαξει μερικα πραγματα ; Μηπως εκει δεν θα υπαρχει impact με την χρηση string σαν primary key; Μηπως εχουν κανει καποιο tweak στον Azure SQL για χρηση primary keys σαν strings ετσι ωστε να μην υπαρχουν προβληματα στην αποδοση;

καλες διακοπες!!! 

Δεν έχω ασχοληθεί με το Mobile Services και έτσι δεν μπορώ να σου απαντήσω. Με SQL Azure databases πάντως μπορείς να βάλεις ότι θέλεις σαν datatype από αυτά που υποστηρίζονται σε αυτό. Δεν έχω δει πουθενά σε όσες τέτοιες databases που έχω φτιάξει να με υποχρεώνει για κάτι τέτοιο.

Το ερώτημα σου όμως το έβαλα στα TODO μου και θα το δω καθώς μου κάνει εντύπωση. Υποψιάζομαι δύο σενάρια αλλά πρέπει να τα επιβεβαιώσω.