PHP 101: Απορίες σχετικά με τους τύπους δεδομένων της SQL

Καλησπέρα σε όλους,

Έχω κάποιες απορίες σχετικά με τους τύπους δεδομένων της SQL
Στη σελ 310 του βιβλίου έχουμε τον κώδικα SQL για τη δημιουργία του πίνακα εκεί που ορίζεται ο τύπος δεδομένων για το πρώτο πεδίο έχουμε:
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT
στη συνέχεια στη σελίδα 312 έχουμε εισαγώγή δεδομένων με:
INSERT INTO table VALUES('NULL' ,...

α) Τί είδους καταχώρηση θα κάνουμε με το 'NULL' ενώ ορίσαμε πρίν οτι δεν μπορεί το πεδίο να είναι NULL.
Η εγγραφή γίνεται και παίρνει πράγματι τον επόμενο αύξοντα αριθμό αλλά δεν κατάλαβα πώς?

β) Το ΙΝΤ χωρίς πρόσημο εξασφαλίζει τη δυνατότητα 4.294.967.295 καταχωρήσεων στην εφαρμογή. Πράγμα που βρίσκω υπερ-αισιόδοξη προοπτική για την εφαρμογή μου (τηλεφωνικός κατάλογος), αν χρησιμοποιήσω το SMALLINT γιατί υπολογίζω να έχω μέχρι 65535 εγγραφές, αντί του ΙΝΤ τί είναι αυτό που θα κερδίσω στη βάση δεδομένων?

γ) Έναν αριθμό τηλεφώνου μπορούμε να τον καταχωρήσουμε σαν αριθμό ή και σαν VARCHAR. Τί μας συμφέρει από την άποψη "όγκου δεδομένων" όταν με τον καιρό αυξηθούν οι εγγραφές ποιό από τα δύο καταλαμβάνει λιγότερο χώρο στη βάση?

Ευχαριστώ πολύ

Άγγελε, από την στιγμή που το πεδίο είναι auto increment δεν θα μπορούσε να είναι NULL η τιμή του καθώς η ίδια η MySQL θα δημιουργήσει μια τιμή για αυτό. Εμείς από την άλλη, καθώς δεν έχουμε πλέον έλεγχο στο πεδίο, οφείλουμε να μήν περάσουμε μια τιμή στο πεδίο ώστε η MySQL να δημιουργήσει την τιμή για 'μας. Επομένως, στέλνουμε μια κενή τιμή.

Αυτό που θα μπορούσες επιπλέον να κερδίσεις είναι στο συνολικό μέγεθος της βάσης. Άλλο μέγεθος θα δεσμευτεί για το πεδίο του πίνακα αν το ορίσεις ως BIGINT και άλλο αν το ορίσεις ως SMALLINT. Σαν γενικό κανόνα κοιτάμε να χρησιμοποιούμε τύπους πεδίων που μας εξυπηρετούν χωρίς να υπερβάλλουμε αλλά και χωρίς να βρεθούμε κάποια στιγμή στο μέλλον να μας έχουν 'τελειώσει' οι τιμές του SMALLINT. Αυτός ο κανόνας έχει περισσότερο εφαρμογή στα πεδία χαρακτήρων, όπου δηλώνουμε VARCHAR και πρέπει να υπολογίσουμε περίπου το μέγεθος του αλφαριθμητικού. Φυσικά, δεν χρησιμοποιούμε TEXT για να αποθηκεύσουμε ένα όνομα όπως δεν είναι και λογικό να χρησιμοποιήσουμε VARCHAR(200).

Για τα μεγέθη δες εδω: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

Έχε υπόψη σου ότι η μικρότερη DB είναι συνήθως και η γρηγορότερη.

Εμφάνιση γονέα

Στέλιο,

Ευχαριστώ για τις παρατηρήσεις και για το link με τις τιμές είναι αυτό που ήθελα
στέκομαι λίγο όμως σε αυτό που γράφεις για το "άν μας έχουν 'τελειώσει' οι τιμές του SMALLINT"
Αν τελειώσουν οι τιμές θα υπάρξει κάποιο πρόβλημα αν αλλάξουμε το πεδίο με ALTER TABLE και το κάνουμε MEDIUMINT.

Επίσης αν το `id` έχει οριστεί σε AUTO_INCREMENT και διαγράψουμε για παράδειγμα τη 2η εγγραφή από τις 10 εγγραφές ενός πίνακα το id=2 θα μείνει κενό. Υπάρχει εντολή να κάνουμε επανακατανομή των id? Δηλαδή το 3 να γίνει 2 το 4->3 κ.ο.κ Έτσι ώστε να υπάρχει μια λογική σειρά στις εγγραφές που να σχετίζεται με το id? και να μη σπαταλάμε id..

Ευχαριστώ.

Εμφάνιση γονέα

Άγγελε, δεν νομίζω πως υπάρχει εύκολος τρόπος να κάνεις κάτι τέτοιο, εκτός από το να κάνεις export τα δεδομένα του πίνακα, drop τον πίνακα, create τον πίνακα και import τα δεδομένα πάλι ώστε το auto-increment να τα αριθμήσει σωστά και συνεχόμενα.

Πρέπει να προσέξεις ότι συνήθως τα ids, ακόμα και αυτά που προέρχονται από auto-increment πεδία τα χρησιμοποιούμε για να δημιουργήσουμε σχέσεις ανάμεσα στους πίνακες. Έτσι όταν έχεις έναν χρήστη με id 50 και χρησιμοποιείς το id αυτό για τον 'συνδέσεις' πχ. με ένα σύνολο αντικειμένων όπως φωτογραφίες, όταν αλλάξεις το id του χρήστη και ο χρήστης μετά το re-arrange πάρει το id 45, τότε οι φωτογραφίες θα 'συνδεθούν' με τον επόμενο χρήστη που θα πάρει το id 50. Ο χρήστης με το id 45 πλέον θα βλέπει διαφορετικές φωτογραφίες.

Εμφάνιση γονέα