Προς το περιεχόμενο

Γνώμες και προτάσεις για κανονικοποίηση βάσης.


QSpec

Προτεινόμενες αναρτήσεις

Δημοσ.

Καλησπέρα,

 

θέλω να φτιάξω μια βάση δεδομένων για μια εφαρμογή αλλά κάτι δεν μου κάθεται καλά με το design στο οποίο καταλείγω. Η εφαρμογή θα παρουσιάζει διάφορα καταστήματα στην Αθήνα ανά περιοχή. Ο admin θα προσθέτει καταστήματα και users και ο κάθε user θα μπορεί να αλλάζει στοιχεία στο κατάστημα του. Οι unregistered users απλά θα βλέπουν διάφορες πληροφορίες για κάθε κατάστημα. Επίσης ανάλογα την μέρα θα παρουσιάζονται διαφορετικές πληροφορίες (στις 23 του μηνος ισχύει η τάδε προσφορά, για παράδειγμα). Κλείνω προς το ακόλουθο design:

 

Πίνακας Users με ID, USERNAME και PASS.

 

Πίνακας Shop με πολλά και διάφορα columns σχετικά με το κατάστημα. Ενδεικτικά: ADDRESS, AREA, USER_ID, NAME, DATE (ημερομηνία προσφοράς που ανέφερα παραπάνω).

 

Πίνακας Admin για τον/τους admin.

 

Κοιτώντας το λοιπόν δεν μου φέρνει σε μια κανονικοποιημένη βάση. Ο πίνακας Shop θα έχει πολλές πληροφορίες οι οποίες πιστεύω πως μπορούν να σπαστούν σε άλλους πίνακες. Από την άλλη σκέφτηκα να κάνω πίνακες ανά περιοχή και να βάλω εκεί τα καταστήματα, αλλά δεν βρίσκω λόγο να το κάνω. Επίσης έλεγα να διαχωρίσω τις ημερομηνίες προσφορών, αλλά πάλι πιστεύω πως με το παραπάνω design δεν θα έχει πρόβλημα. Η εφαρμογή θα διαχειρίζεται 1000 με 1500 καταστήματα, αυτό σημαίνει πως ο πίνακας Shop θα έχει 1500 entries, πιστεύετε πως θα επηρεάσει συμαντικά την ταχύτητα των queries;

 

Εσείς πως θα σχεδιάζατε μια τέτοια βαση;

 

Ελπίζω να έγινα κατανοητός B)

Δημοσ.

Σίγουρα θα επηρεάσει την ταχύτητα των queries ένας πίνακας με πολλές εγγραφές και πολλά πεδία να έχει ο πίνακας.

 

Π.χ. θα μπορούσες να σπάσεις τον κύριο σου πίνακα σε έναν πίνακα με κάποιες λεπτομέρειες για το κατάστημα.

 

Πόσα columns πιστεύει θα έχει πίνακας με τα shops?

Δημοσ.

Max 15.

 

Από τα 15 τα 7 θα καλούνται σε κάθε προβολή του καταστήματος και άλλα 5 θα καλούνται εάν ο ιδιοκτήτης (user) έχει προσθέσει στοιχεία.

 

Χμμ, θα μπορούσα να τον σπάσω σε έναν με τα στοιχεία που καλούνται πάντα και σε έναν με τα "προεραιτικά" στοιχεία.

Δημοσ.

Για τέτοιο αριθμό πεδίων δεν αξίζει να κάνεις τέτοιο διαχωρισμό (εκτός και αν τα πεδία είναι fulltext ή blob).

 

Ενδεικτικά σου προτείνω το παρακάτω σχεδιασμό:

Users:

id,

username,

password,

name,

shop_id,

isadmin,

isactivated,

created

 

Shops:

id,

name,

address,

area_id,

created

 

Offers:

id,

shop_id,

user_id,

startdate,

enddate,

title,

description,

created

 

Areas:

id,

name,

area_id

Δημοσ.

Κατέληξα σε 3 πίνακες, έναν για τους users, έναν για τις πληροφορίες του καταστήματος και ένα για τις extra πληροφορίες. Αφού το μέγεθος δεν είναι μεγάλο ένας διαχωρισμός είναι αρκετός πιστεύω.

 

Ευχαριστώ για τις απαντήσεις. :)

Αρχειοθετημένο

Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.

  • Δημιουργία νέου...