Καλώς ορίσατε στο dotNETZone.gr - Σύνδεση | Εγγραφή | Βοήθεια
σε

 

Αρχική σελίδα Ιστολόγια Συζητήσεις Εκθέσεις Φωτογραφιών Αρχειοθήκες

Guid

Îåêßíçóå áðü ôï ìÝëïò gianestras. Τελευταία δημοσίευση από το μέλος Antonios Chatzipavlis στις 28-03-2016, 20:31. Υπάρχουν 5 απαντήσεις.
Ταξινόμηση Δημοσιεύσεων: Προηγούμενο Επόμενο
  •  24-03-2016, 02:11 77632

    Guid

    καλημέρα σας.. 

    Εξασφαλίζεται η μοναδικότητα, πάντα, σε έναν πίνακα πχ Users, της στήλης που γεμίζει με Guid.NewGuid() ;

     

     

  •  24-03-2016, 08:50 77633 σε απάντηση της 77632

    Απ: Guid

    The answer is YES and FYI https://en.wikipedia.org/wiki/Globally_unique_identifier

    Also just in case please read this http://sqlschool.gr/blog/uniqueidentifier-data-type-as-table-primary-key-or-clustered-index-56.aspx 
     

     


    Antonios Chatzipavlis

  •  24-03-2016, 13:26 77634 σε απάντηση της 77633

    Απ: Guid

    Εδώ που τα λέμε, γιατί να φτιάξεις το GUID στον client και να μην ορίσεις το NEWSEQUENTIALID() σαν default τιμή της στήλης? Το αντίστοιχο στον client είναι να καλέσεις το UuidCreateSequential :

       [DllImport("rpcrt4.dll", SetLastError=true)]
       public static extern int UuidCreateSequential(out Guid guid);


    Παναγιώτης Καναβός, Freelancer
    Twitter: http://www.twitter.com/pkanavos
  •  28-03-2016, 15:29 77641 σε απάντηση της 77634

    Απ: Guid

    Αντώνη είσαι πάντα μία αστείρευτη πηγή γνώσης για τον SQL Server και επισκέπτομαι συχνά το site σου. Θα ήθελα να πω και εγώ δύο λόγια για το GUID, μιάς και είναι μία επιλογή που χρησιμοποιώ εδώ και χρόνια και να απαντήσω και στον Παναγιώτη για ποιον λόγο η επιλογή του NEWSEQUNETIALID() στον server δεν είναι η καλύτερη, για αρκετές περιπτώσεις θα έλεγα, πάντα με την εμπειρία που έχω σε δουλειές που έκανα.

    Για εμένα το μεγαλύτερο πλεονέκτημα που έχει η χρήση του GUID σαν primary key είναι για σενάρια merging εγγραφών από διαφορετικές βάσης αλλά και για σενάρια μαζικής καταχώρησης εγγραφών που πρέπει να καταχωρηθούν σε πάνω από ένα πίνακες. Τα παραδείγματα για το δεύτερο σενάριο είναι πολλά. Π.χ εφαρμογές τιμολόγησης που πρέπει να καταχωρήσουν τιμολόγια με τα προϊόντα ή υπηρεσίες. Ασφαλιστικές εταιρείες που δέχονται claims, ναυτιλιακές εταιρείες που καταχωρούν δρομολόγιο με φορτία κ.τ.λ. Στις περιπτώσεις αυτές είναι σημαντικό να γνωρίζεις το id που θα πάρει η κεντρική εγγραφή με βάση την οποία θα καταχωρηθούν και οι υπόλοιπες. Αν βλέπουμε ένα κέρδος για την μία εγγραφή φανταστείτε το κέρδος όταν θέλουμε να καταζωρήσουμε μαζικά πεντήντα τιμολόγια. Όπότε στα σενάρια αυτά δεν σε βοηθάει το NEWSEQUENTIALID() στον server γιατί τότε χάνεις ότι κέρδος έχεις αφού για κάθε καταχώρηση θα πρέπει πρώτα να πας στον server.

    Φυσικά υπάρχουν και προβήματα με την χρήση του GUID σαν primary key και το άρθρο του Αντώνη είναι πολύ καλή πηγή ενημέρωσης. Οπότε πως μπορείς να το αποφύγεις όλο αυτό το μπέρδεμα και να έχεις και το κέρδος στην απόδοση που λέγαμε. Εδώ εγώ προσωπικά έχω επιλέξει την εξής πρόσεγγιση. Να βάλω το GUID σαν primary key το οποίο το κάνω generate από την εφαρμογή μου αλλά να ορίσω για clustered index ένα άλλο πεδίο που αναφέρεται στην ημερομηνία και στην ώρα που καταχωρήθηκαν οι εγγραφές. Επειδή αυτό δεν με ενδιαφέρει να το δίνω εγώ από την εφαρμογή μπορεί να βάζει ο server την ώρα του. Πως βλέπεις αυτήν την προσέγγιση Αντώνη;

    Όσο για αυτό που έγραψες Παναγιώτη με το import δεν το γνωρίζω. Μπορείς να γράψεις λίγο παραπάνω για την λειτουργία του;

     Ευχαριστώ. 

  •  28-03-2016, 15:53 77642 σε απάντηση της 77641

    Απ: Guid

    Γι αυτό και ανέφερα το UuidCreateSequential. Είναι το ίδιο ακριβώς όπως το Guid.New αλλά αυξάνεται σταθερά. Από την άλλη, όταν χρησιμοποιείς ORM η αντιστοίχιση των primary keys γίνεται από το ίδιο το ORM. Αν το ORM είναι καλά γραμμένο, αυτή η αντιστοίχιση γίνεται στο server. 

    Όσο για τη μαζική καταχώρηση εγγραφών, αν μαζική >10 τότε θα πρέπει να υπάρχει διαδικασία ETL και όχι αποστολή εγγραφών μία-μία από τον client. Διαφορετικά και η καταχώρηση αρχίζει να καθυστερεί υπερβολικά και η διαδικασία γίνεται υπερβολικά περίπλοκη. Σε τέτοιες περιπτώσεις είναι πολύ γρηγορότερο και ευκολότερο να φορτώσεις τις εγγραφές από τα διάφορα συστήματα σε staging πίνακες και μετά να τις συνδυάσεις. Αν έχεις απλά 3 συστήματα με 1000 νέες εγγραφές το καθένα, τα αντίστοιχα ETL queries είναι σχεδόν no-op για μία βάση, ενώ η ίδια δουλειά σε κάποιο client θα μπορούσε να καταλήξει από γραμμικά (1000 φορές) ως συνδυαστικά (1000 φορές ανά συνδυασμό συστημάτων) πιο αργή. 

    Αναφέρω το συνδυαστικό γιατί αυτό ακριβώς μου έχει τύχει τελευταία - διαδικασία η οποία ταίριαζε εγγραφές συστημάτων με τιμολόγια στη μνήμη (για να πάει πιο "γρήγορα"). Το αποτέλεσμα ήταν να χρειάζονται Μ*N operations, ανά συνδυασμό και η επεξεργασία έτους ή εξαμήνου να παίρνει μέρες.  Αντικαθιστώντας αυτό το πράγμα με πίνακες στη βάση και σωστό indexing, η ταχύτητα κατέβηκε στα λεπτά. ΟΚ, και με change tracking απλά δεν χρειαζόταν να υπολογίσω τα πάντα, μόνο τις αλλαγμένες εγγραφές. Αυτή τη στιγμή όμως μία διαδικασία matching 800Κ εγγραφών από δύο συστήματα θέλει 90 sec. 


    Παναγιώτης Καναβός, Freelancer
    Twitter: http://www.twitter.com/pkanavos
  •  28-03-2016, 20:31 77643 σε απάντηση της 77641

    Απ: Guid

    Είμαι 100% μαζί σου για την χρήση που αναφέρεις.

     


    Antonios Chatzipavlis

Προβολή Τροφοδοσίας RSS με μορφή XML
Με χρήση του Community Server (Commercial Edition), από την Telligent Systems