Έχω το εξής σχεδιαστικό πρόβλημα και θα ήθελα την γνώμη σας:
Δημιουργώ μία βάση που θα αποθηκεύσει τους πελάτες και τα project τους. Υπάρχει συγκεκριμένος αριθμός τύπων project, που κάθε ένας έχει εντελώς διαφορετικά χαρακτηριστικά το άλλον. Πχ μερικοί τύποι project είναι τα hosting, domain, graphicDesign κλπ. Έχω δημιουργήσει έναν πίνακα για κάθε τύπο project.
Επιπλέον κάθε εγγραφή στους παραπάνω πίνακες έχει 1 ή παραπάνω οικονομικές χρεώσεις που αποθηκεύονται στον πίνακα Financial. Έτσι λοιπόν αυτή τη στιγμή αναγκάζομαι να έχω έναν πίνακα Financial ο οποίος έχει την εξής δομή:
id_financial, id_targetTable, targetTable, other_financial_data...
Στο targetTable κρατάω το όνομα του πίνακα στον οποίο αντιστοιχεί η συγκεκριμένη χρέωση και στο id_targetTable κρατάω το id της εγγραφής του πίνακα.
ΠΧ Έστω ότι έχω μια εγγραφή στην πίνακα Financial με κωδικό 1. Έστω ακόμα ότι η συγκεκριμένη χρέωση αντιστοιχεί σε μια εγγραφή του πίνακα hostingTable με κωδικό 12. Τότε η εγγραφή στον Financial είναι κάπως έτσι:
1, 12, 'hostingTable', other_financial_data...
Ο τρόπος αυτός δεν είναι καλός κατά την γνώμη μου γιατί δεν κάνει χρήση των ξένων κλειδιών της Βάσης και ψάχνω έναν καλύτερο. Σημειώνεται ότι δε γίνεται να βάλλω 1 πεδίο (ξένο κλειδί) id_financial στους πίνακες hostingTable, domainTable, graphicDesignTable κλπ γιατί οι χρεώσεις σε κάθε εγγραφή μπορεί να είναι από 1 έως n.
Υπάρχει κάποιος καλύτερος τρόπος σχεδίασης της βάσης για το παραπάνω; Υπάρχει τρόπος να χρησιμοποιήσω πραγματικά ξένα κλειδιά;
--
Σημειώνεται η παρακάτω λύση δεν είναι καθόλου καλή:
- Φτιάχνω έναν ενδιάμεσο πίνακα για κάθε έναν από τους πίνακες των project, στον οποίο σώζω την αντιστοιχία id_targetTable, id_financial (πχ για τον πίνακα hosting έχω το ζευγάρι id_hostingTable, id_financial)
- Δείχνω το id_targetTable στο πρωτεύον κλειδί του πίνακα με το συγκεκριμένο τύπο project και το id_financial στο πρωτεύον κλειδί του πίνακα financial (πχ για τον ενδιάμεσο πίνακα hostingMiddle το id_hostingTable θα δείχνει στο κλειδί του hostingTable και το id_financial στο financial).
Αυτή η λύση είναι ιδιαίτερα κακή από άποψη ταχύτητας γιατί προσθέτει ακόμα περισσότερους πίνακες, χρειάζεται τριπλό join για να πάρεις αποτελέσματα και δε μπορείς σε καμία περίπτωση να ξέρεις άμεσα μια εγγραφή Financial που πρέπει να την ψάξεις. Το τελευταίο σημαίνει ότι για να βρεις μια εγγραφή Financial που αντιστοιχεί θα πρέπει να ψάξεις σε όλους τους ενδιάμεσους πίνακες ώστε να πετύχεις το id_Financial και ύστερα να κάνεις την αντιστοίχιση με το project.