Πχ έχω τους πίνακες Α και Β με primary keys int A_ID & B_ID αντίστοιχα

---

"When the darkness rises up from inside - that is normal.
It's when you reach down to pull it up - that the noxious warnings sound."
Tuzak, Farscape

Προτού γράψω τη γνώμη μου θα ήθελα να ρωτήσω αν το business logic είναι σωστό. Νομίζω ότι από τη στιγμή που για το C πρέπει να κρατηθεί επιπλέον πληροφορία μιλάμε για αυθύπαρκτο object και όχι για many to many relationship. Ένα τέτοιο παράδειγμα αποτελεί το: Μαθητής - Καθηγητής - Εξέταση. Η "Εξέταση" έχει ημερομηνία, μάθημα, βαθμό και βεβαίως τον Καθηγητή που εξετάζει και τον Μαθητή που εξετάζεται. Και αν θέλουμε να ορίσουμε ένα composite key γι' αυτήν τότε, εκτός των πεδίων Μαθητής - Καθηγητής, πρέπει να συμπεριλάβουμε την ημερομηνία, αλλά και το μάθημα. Δηλαδή, ΔΕΝ ισχύει η μοναδικότητα του συνδυασμού "Μαθητής - Καθηγητής".

Αντίστοιχα, κλασικό many to many παράδειγμα αποτελεί το Συγγραφείς - Βιβλία. Το ότι ένα βιβλίο μπορεί να έχει περισσότερες της μίας εκδόσεις, αυτό δεν πρέπει να μας μπερδεύει γιατί κάθε έκδοση είναι και ξεχωριστό βιβλίο. Μπορεί ο τίτλος να παραμένει ο ίδιος, αλλά το ISBN αλλάζει. Αν, λοιπόν, επιλέξουμε να δημιουργήσουμε διαφορετικό πεδίο για την έκδοση, τότε για το πεδίο του τίτλου πρέπει να μεριμνήσουμε ώστε το index που θα δημιουργήσουμε να μην είναι unique. Έτσι, δεν "διαταράσσεται" η "αρχή" του many to many relationship.

Θα ήθελες να δώσεις λίγα παραπάνω στοιχεία για τα A, B, C και το είδος της πληροφορίας που θέλεις να γράψεις στο C; Σίγουρα ο συνδυασμός 'ΑΒ' είναι μοναδικός; Αν ναι, μήπως η επιπλέον πληροφορία πρέπει να κρατηθεί είτε στο A object είτε στο B object, όπως στην περίπτωση "Βιβλίο - Συγγραφέας";

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Ευχαριστώ για την απάντηση Μάρκο, ιδού και τα λοιπά στοιχεία λοιπόν:

---

"When the darkness rises up from inside - that is normal.
It's when you reach down to pull it up - that the noxious warnings sound."
Tuzak, Farscape

Αν κατάλαβα καλά, μιλάμε για audit trail. Δε χρειάζεται να συσχετίσεις πίνακες μεταξύ τους. Όλη την "κίνηση" μπορείς να την καταγράψεις σε έναν πίνακα. Αν δώσεις στο Google "entity framework audit trail" ή "ado.net audit trail" θα έρθουν πολλά αποτελέσματα. Δε συστήνω κανένα από αυτά στο σύνολό του. Μπορείς να τα μελετήσεις όλα και να συνθέσεις κάτι δικό σου, που θα εξυπηρετήσει ακριβώς τις ανάγκες σου. Ένα παράδειγμα είναι το "Auditing Data Changes in the Entity Framework", Part 1 και Part 2 ή αντίστοιχο δημοσίευμα στο Code Project (Part 1, Part 2). Σχετικές συζητήσεις έχουν γίνει και στο DNZ. Προσωπικά, για κάτι τέτοιο θα χρησιμοποιούσα stored procedures.

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

Λάθος δικό μου, δεν πρόκειται για audit trail - τα άρθρα που παρέθεσες πάντως το καλύπτουν πλήρως.

---

"When the darkness rises up from inside - that is normal.
It's when you reach down to pull it up - that the noxious warnings sound."
Tuzak, Farscape

Δεν παίρνω θέση. Ας μιλήσουν κι άλλοι. Ένα καλό σημείο αφετηρίας είναι αυτή η συζήτηση. Νομίζω ότι είναι κοντά σ' αυτό που θέλεις να κάνεις. Καμιά φορά δεν είναι κακό να συζητάμε για πράγματα που θεωρούνται δεδομένα και αυτονόητα.

---

Ακόμα κι ένας άνθρωπος μπορεί ν' αλλάξει τον κόσμο. Μη θέλεις να κυβερνήσεις. Απλά δείξε το μονοπάτι κι ο κόσμος θ' ακολουθήσει!!

---

"When the darkness rises up from inside - that is normal.
It's when you reach down to pull it up - that the noxious warnings sound."
Tuzak, Farscape