Θα ήθελα τη γνώμη σας για ένα σχετικά μικρό σύστημα, για business environment, με 15 έως 20 χρήστες το πολύ, όπου ο καθένας κάνει τη δουλειά του.

Πιστεύετε ότι υπάρχει ενδεχόμενο να παρουσιαστούν concurrency cases/issues και άρα θα πρέπει να εφαρμοστεί κάποια μέθοδος transaction isolation?

Η απάντηση στην ερώτηση αυτή είναι ότι εφόσον έχει ακολουθηθεί ο κανόνας του open connection late - close connection early αλλά και όσα αναφέρω παρακάτω

http://www.sqlschool.gr/blog/error-1205-or-a-deadlock-occurred-how-to-deal-with-it-756.aspx δεν βλέπω το λόγο να χρησιμοποιηθεί κάποιο ιδιαίτερο isolation level.

Φυσικά θα πρέπει να επισημάνω ότι όλα είναι σχετικά με το πως έχει σχεδιαστεί η βάση δεδομένων αλλά και πως έχει γραφτεί η εφαρμογή

Φιλικά 

Ενδεχόμενο υπάρχει ακόμα και με 2 άτομα, μήν πω και με 1, αν ο κώδικας και η σχεδίαση της βάσης είναι κακή. Transaction isolation υπάρχει πάντα - είναι ο μηχανισμός της οποιαδήποτε βάσης ο οποίος εξασφαλίζει ότι αλλαγές που γίνονται από ένα connection δεν θα χαλάσουν τα δεδομένα που βλέπει ένα άλλο connection.

Δεν δίνεις κανένα ουσιαστικό στοιχείο (π.χ. εκτιμώμενος όγκος (MB αλλά και γράμμές) πλήθος πινάκων, συχνότητα κλήσεων, είδος query, είδος χρήσης) για το τί θα γίνεται με τη βάση οπότε μόνο τα "γενικά" μπορεί να πει κανείς:

• Ποτέ μα ποτέ μην κρατάς ένα  transaction ανοικτό παραπάνω απ' όσο χρειάζεται. Ποτέ μην κάνεις υπολογισμούς στον client έχοντας ανοικτά transactions
• Φρόντισε να έχεις σωστά indexes για όλους τους πίνακες και να ανανεώνεις συχνά τα statistics. 
• Μην προσπαθείς να γράψεις "περίεργα" queries με LINQ ή όποια γλώσσα υποστηρίζει το ORM σου. Η SQL που παράγεται συνήθως είναι περίεργη, αργή, ή δεν κάνει αυτό που νομίζεις. Καλύτερα φτιάξε views και stored procedures που θα κάνουν αυτό που θέλεις.
• Αντί να χτυπάς τη βάση για να πειράξεις μία-μία γραμμή, πχ. σε loop, γράψε το κατάλληλο query που θα πειράξει ή θα διαβάσει όλες τις γραμμές που χρειάζεσαι με τη μία.
• Μην κρατάς ένα connection ανοικτό για πάντα. Το connection pooling εξασφαλίζει ότι δεν κοστίζει τίποτε να το κλείνεις αμέσως όταν δεν το χρειάζεσαι. Έτσι αποφεύγεις να μαζευτούν locks από ξεχασμένα transactions
• Χρησιμοποίησε optimistic concurrency αντί για transactions. Χονδρικά, το ORM/API που χρησιμοποιείς κοιτάζει αν κάποιος άλλος έχει αλλάξει τα δεδομένα που προσπαθεί να γράψει και σου "φωνάζει" αν έχουν πειραχτεί. Η τεχνική υποστηρίζεται από όλα τα ORMs, με τα οποία μάλιστα όλες οι αλλαγές μπορούν να μαζευτούν και να αποθηκευτούν σαν πακέτο. Transactions χρησιμοποιούνται μόνο όταν σώζεται ολόκληρο το batch
• Μην εκτελείς reporting πάνω σε transactional (OLTP) δεδομένα. Από τη μία κάθε σενάριο χρειάζεται διαφορετικό σχήμα, από την άλλη όσο εκτελείται ένα βαρύ reporting query θα καθυστερούν όλες οι αλλαγές. Φτιάξε μία άλλη reporting database της οποίας το schema θα διευκολύνει το reporting και κάνε περιοδικά update με τα δεδομένα της online.

Αν και καθυστερημένα σας ευχαριστώ όλους για τις απαντήσεις σας.

Προς το παρόν δεν θα προσθέσω κάτι.