Υπάρχουν λίγες δεκάδες (3-4) tables στα οποία είναι καταχωρημένα διαφορετικού τύπου δεδομένα. Χρήστες, ομάδες μελών, μαθήματα, εξετάσεις, αρχεία, υλικό, κτλ. (ένα παράδειγμα για το semfe.gr). Κάθε group από χρήστες έχει μια σειρά από δικαιώματα (READ, WRITE, MODERATE):
- READ: Μπορεί μόνο να αναγνώσει τις πληροφορίες των εγγραφών του table
- WRITE: Μπορεί να δημιουργήσει, τροποποιήσει ή διαγράψει μια εγγραφή, αλλά η "εντολή" του δεν υλοποιείται άμεσα. Περνάει σε έναν πίνακα στον οποίο αναμένει για έγκριση από κάποιον moderator
- MODERATE: Μπορεί να κάνει ό,τι και αυτός που έχει πρόσβαση WRITE χωρίς να ζητήσει έγκριση ή να περιμένει, και ελέγχει και εγκρίνει/απορρίπτει τις "αιτήσεις" καταχωρήσεων των χρηστών με WRITE πρόσβαση.
Άλλη μια λειτουργία είναι ο συσχετισμός εγγραφών διαφορετικών tables οι οποίοι συνδέονται και εντάσσονται σε έναν φάκελο. Π.χ. υπάρχει μια εγγραφή τύπου "Αρχείο" και μια εγγραφή (σε άλλο table) τύπου "Μάθημα", και θέλω να συσχετίσω αυτά τα δυο και να τα εντάξω στον φάκελο "Θέματα Εξετάσεων".
Να σημειώσω, επίσης, ότι η εφαρμογή έχει μηχανισμό με τον οποίο αντιστοιχίζει ένα σταθερό και μοναδικό ID για κάθε table ώστε να αναγνωρίζεται μονοσήμαντα και εύκολα.
Οι παραπάνω, καθώς και άλλες ακόμα λειτουργίες και εφαρμογές, (ειδικά όταν μιλάμε για σχέσεις many-to-many όπως στoυς Φακέλους με υλικό και μαθήματα, κτλ.) χρειάζονται κάποια "cross-table" references. Έτσι έχουν προκύψει αρκετοί πίνακες που πρέπει να έχουν αναφορές σε αντικείμενα (rows/items) που μπορεί να ανήκουν σε ένα από πολλά υποψήφια tables. Άρα εκτός από το ID, για να περιγραφεί το item πρέπει να αποδοθεί και το ID του πίνακα.
Φτάνουμε, λοιπόν, να έχουμε (προς το παρόν τουλάχιστον, ποτέ δεν ξέρεις τι προκύπτει) ένα σωρό tables τα οποία χρειάζονται δυο στοιχεία (table id, item id) για να περιγραφούν. Δεν με ενοχλεί ο χώρος τόσο πολύ (πρέπει να έχεις δυο columns), όσο το ότι προγραμματιστικά γίνεται λίγο δύσκαμπτο αυτό το σύστημα.
Σκέφτηκα, λοιπόν, να κάνω το εξής: Να ορίσω ένα table στο οποίο εγγραφές που χρησιμοποιούνται σε παραπάνω λειτουργίες, να ορίζουν εκεί το table στο οποίο βρίσκονται καθώς και άλλες unique ιδιότητες (που μοιράζονται ΟΛΕΣ οι εγγραφές, ανεξαρτήτως table, όπως στοιχεία δημιουργίας, επίπεδα πρόσβασης, κτλ.) και να τα συσχετίζω σε ένα global ID. Η αρχική δομή που σκέφτηκα ήταν η εξής:
- global_item_id: Το unique (global) ID που χαρακτηρίζει τη συγκεκριμένη εγγραφή μέσα στον πίνακα (index, auto_increment)
item_table: Τον πίνακα στον οποίο ανήκει η εγγραφή στην οποία αναφερόμαστε
local_item_id: Το ID της εγγραφής τοπικά μέσα στον πίνακα. Αυτό αντιστοιχεί στο id (index, auto_increment) που έχει οριστεί στον πίνακα (item_table).
- Στον πίνακα τοπικά, ένα ID που θα ξεχωρίζει την εγγραφή από τις άλλες στο ίδιο table. Ο τύπος μπορεί να είναι από tinyint μέχρι int.
- Στον global πίνακα ένα index που θα ξεχωρίζει τα διαφορετικά μεταξύ τους cross-table item references. Θα έιναι int ώστε να μην εξαντληθεί
- Στον global Πίνακα, αντίγραφο του τοπικού ID ώστε να εντοπίζεται εύκολα. Θα είναι int καθώς η χειρότερη περίπτωση local ID είναι int
- Στον ίδιο global πίνακα, το ID του table στο οποίο κατοικεί πραγματικά η εγγραφή. Ένα tinyint (αν έχεις πάνω από 255 πίνακες έχεις άλλα προβλήματα)
Αυτό προς το οποίο κλίνω είναι να καταργήσω τελείως το local ID. Δηλ. κάθε πίνακας του οποίου οι εγγραφές πρόκεται να έχουν τέτοια κομφορτ, δε θα ορίζουν ένα δικό τους auto_increment id (που θα'ναι και index). Επίσης, έτσι θα αφαιρεθεί και το Local item id από τον global πίνακα. Αντ' αυτού σκέφτομαι να κάνω το εξής:
Όποτε πρέπει να προστεθέι μια εγγραφή σε κάποιον πίνακα, πάω πρώτα και κάνω μια καταχώρηση στον Global. Το global ID θα μου δώσει ένα Unique ID (μεγέθους int) το οποίο θα είναι τώρα Unique ανάμεσα σε ΟΛΟΥΣ τους πίνακες που διαθέτω. Όταν πάρω αυτό το ID θα κάνω καταχώρηση της εγγραφής στον ιδιαίτερο πίνακά της, καθ θα βάλω στη θέση του πάλαι ποτέ local unique ID το ID που μου έδωσε η global Καταχώρηση.
Έτσι παντού οι εγγραφές (και στους ίδιους τους πίνακες που ορίζονται, και σε εκείνους που κάνουν συνδέσεις ή προσφέρουν επιπλέον πληροφορίες, όπως αυτά που ανέφερα αρχικά) θα αναφέρονται με ένα Unique global ID (μεγέθους Int) γλιτώνοντας τα tinyints που χρειαζόμουν για τα tables.
Υπάρχουν, όμως, κάποια αρνητικά:
- Ενώ το local id κάθε εγγραφής είχε μέγεθος που αντιστοιχούσε στις πραγματικές ανάγκες, τώρα αναγκαστικά θα γίνει Int (καθώς έτσι επιβάλλει το global ID)
- Αυτό προκύτπτει από το γεγονός ότι τα IDs είναι αραιά όταν τα βλέπει κανείς τοπικά. Δηλ. μπορεί σε έναν πίνακα η πρώτη εγγραφή σου να είναι η ID=3 και η επόμενη να έχει ID=42300. Κι αυτό όχι επειδή οι ενδιάμεσες διαγράφηκαν, αλλά επειδή αποδόθηκαν ως ID σε εγγραφές άλλων tables.
- Αντιστοίχως μεγαλώνουν τα indexes της MySQL καθώς πρέπει να αποθηκεύουν IDs μεγέθους int.
