AI και Βάσεις Δεδομένων MySQL

Ένα αξιοσημείωτο σφάλμα είναι ότι πολλά σχήματα βάσεων δεδομένων που δημιουργούνται από AI επί του παρόντος τείνουν να ευνοούν τη χρήση του VARCHAR(36) για τη στήλη id.

Αυτό συνήθως παρακινείται από μια επιθυμία να αποτραπεί η μη εξουσιοδοτημένη πρόσβαση από κακόβουλους παράγοντες. Για να επιτευχθεί αυτό, τα UUID (Universally Unique Identifiers) χρησιμοποιούνται συχνά ως μέτρο ασφάλειας.

Ας πάρουμε το WordPress ως παράδειγμα — συνήθως εκθέτει ID δημοσιεύσεων στη διεύθυνση URL ως ?p=45. Σε σύγκριση με ένα φιλικό προς SEO μορφότυπο όπως /2025/05/sample-post, αυτό το αριθμητικό ID επιτρέπει στους χρήστες να μαντεύουν και να αποκτούν πρόσβαση σε παρακείμενο περιεχόμενο αλλάζοντας τον αριθμό (π.χ. ?p=44). Τα UUID από την άλλη πλευρά δεν είναι διαδοχικά και είναι πολύ πιο δύσκολα να μαντευτούν.

Τα UUID είναι συμβολοσειρές 36 χαρακτήρων που ακολουθούν ένα τυπικό μορφότυπο με πέντε τμήματα διαχωρισμένα με παύλες: 8-4-4-4-12. Κάθε τμήμα αποτελείται από δεκαεξαδικές τιμές:

550e8400-e29b-41d4-a716-446655440000
f47ac10b-58cc-4372-a567-0e02b2c3d479
123e4567-e89b-12d3-a456-426614174000

Ένα απλό regex για την επικύρωση UUID μοιάζει έτσι:

^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$

Ενώ τα UUID προσφέρουν ασφάλεια και φορητότητα, έρχονται με συμβιβασμούς. Είναι σημαντικά μεγαλύτερα από τους ακέραιους, κάτι που μπορεί να επιβραδύνει την απόδοση της βάσης δεδομένων — ειδικά όταν χρησιμοποιούνται ως πρωτεύοντα κλειδιά σε σχεσιακές βάσεις δεδομένων. Η ευρετηρίαση, η χρήση μνήμης και η ταχύτητα ερωτημάτων υποφέρουν όλα λόγω του μεγέθους και της μη διαδοχικής φύσης των UUID.

Μια συνομιλία AI για στρατηγική ID

Περίεργος για αυτή την επιλογή σχεδίασης, έθεσα στον GitHub Copilot την ακόλουθη ερώτηση:

Εγώ:
Γιατί επιλέξατε να ορίσετε τη στήλη id ως VARCHAR(36) PRIMARY KEY στη δομή της βάσης δεδομένων;

GitHub Copilot:

Επέλεξα VARCHAR(36) για τις στήλες ID για μερικούς συγκεκριμένους λόγους:

1. Αποθήκευση UUID: Το μήκος 36 χαρακτήρων περιλαμβάνει τιμές UUID, οι οποίες ακολουθούν ένα τυποποιημένο μορφότυπο.
2. Συστήματα πολλαπλών ενοικιαστών: Τα UUID βοηθούν στην απομόνωση των ενοικιαστών εξαλείφοντας τις διαρροές διαδοχικών ID, απλοποιώντας τις μεταναστεύσεις και βελτιώνοντας την ασφάλεια.
3. Φορητότητα δεδομένων: Τα UUID διασφαλίζουν ότι τα εξαγόμενα δεδομένα δεν θα υποστούν συγκρούσεις ID κατά την εισαγωγή σε άλλο σύστημα.

Συμβιβασμοί:

• Μεγαλύτερο μέγεθος αποθήκευσης (36 bytes vs. 4 bytes για INT)
• Πιο αργή απόδοση ευρετηρίασης και ερωτημάτων
• Υψηλότερη χρήση μνήμης

Εναλλακτικές για εξέταση:

1. AUTO_INCREMENT INT/BIGINT
2. BINARY(16) για πιο αποτελεσματική αποθήκευση ακατέργαστων UUID bytes
3. Μια προσαρμοσμένη στρατηγική δημιουργίας ID

Ενημερώστε με αν προτιμάτε διαφορετική προσέγγιση.

Εγώ:
Χρησιμοποιήστε BIGINT UNSIGNED για απόδοση, αλλά διατηρήστε ένα πεδίο guid σε κάθε εγγραφή για εξωτερικές αναφορές.

GitHub Copilot:

Θα ενημερώσω το σχήμα για να χρησιμοποιεί BIGINT UNSIGNED ως πρωτεύον κλειδί προσθέτοντας μια στήλη guid για εξωτερικές αναφορές. Αυτή η υβριδική προσέγγιση συνδυάζει το καλύτερο και των δύο στρατηγικών:

• Απόδοση: Αποτελεσματική ευρετηρίαση και συνδέσεις μέσω αριθμητικών πρωτευόντων κλειδιών
• Ασφάλεια και φορητότητα: GUID εκτεθειμένα σε API, διατηρώντας τα εσωτερικά ID ασφαλή από απαρίθμηση

Περίληψη:

• BIGINT UNSIGNED: Γρήγορο, συμπαγές, διαδοχικό
• GUID (VARCHAR): Μοναδικό, φορητό, εξωτερικά ασφαλές

Βάσεις δεδομένων NoSQL και MongoDB ObjectIds

Ενώ οι σχεσιακές βάσεις δεδομένων προσφέρουν ευελιξία στην επιλογή μεταξύ UUID, ακεραίων ή υβριδίων, τα συστήματα NoSQL όπως το MongoDB παίρνουν διαφορετικό δρόμο.

Το MongoDB χρησιμοποιεί έναν ενσωματωμένο τύπο που ονομάζεται ObjectId για το πεδίο _id του. Αυτή είναι μια δυαδική τιμή 12 bytes που κωδικοποιεί:

• 4 bytes – Χρονοσφραγίδα (δευτερόλεπτα από την εποχή)
• 5 bytes – Τυχαία τιμή (συχνά βασισμένη σε μηχάνημα + ID διεργασίας)
• 3 bytes – Αυξητικός μετρητής

Παράδειγμα:

507f1f77bcf86cd799439011

Γιατί το MongoDB επιλέγει ObjectId

1. Παγκοσμίως μοναδικό χωρίς συντονισμό
   Όπως τα UUID, τα ObjectIds δεν απαιτούν κεντρική αρχή για να εξασφαλίσουν τη μοναδικότητα, καθιστώντας τα ιδανικά για κατανεμημένα περιβάλλοντα.
2. Χρονικά ταξινομημένο
   Η ενσωματωμένη χρονοσφραγίδα σημαίνει ότι τα έγγραφα είναι χρονολογικά ταξινομημένα από προεπιλογή, κάτι που μπορεί να βοηθήσει με την απόδοση σε εφαρμογές χρονοσειρών.
3. Συμπαγές και αποτελεσματικό
   Αποθηκευμένα σε δυαδική μορφή, τα ObjectIds καταλαμβάνουν μόνο 12 bytes — πολύ μικρότερα από ένα UUID VARCHAR(36). Είναι επίσης πιο φιλικά στην ευρετηρίαση.

Σύγκριση στρατηγικών ID

Προτιμήσεις AI σε πλαίσια NoSQL

Πολλά συστήματα που δημιουργούνται από AI προεπιλέγουν σε διαμορφώσεις NoSQL παρόμοιες με MongoDB όταν:

• Αναμένεται υψηλή απόδοση εγγραφής ή sharding
• Τα σχήματα πρέπει να είναι ευέλικτα ή ημι-δομημένα
• Η φορητότητα δεδομένων και η κατανεμημένη κλιμάκωση είναι προτεραιότητες

Σε τέτοιες περιπτώσεις, η χρήση ObjectIds ή παρόμοιων μοναδικών, χρονικά ταξινομήσιμων αναγνωριστικών είναι συχνά μια λογική προεπιλεγμένη επιλογή.

PrimeCRM