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

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

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 
 

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

   [DllImport("rpcrt4.dll", SetLastError=true)]
   public static extern int UuidCreateSequential(out Guid 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 δεν το γνωρίζω. Μπορείς να γράψεις λίγο παραπάνω για την λειτουργία του;

 Ευχαριστώ. 

Γι αυτό και ανέφερα το 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. 

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