QSpec Δημοσ. 23 Σεπτεμβρίου 2008 Δημοσ. 23 Σεπτεμβρίου 2008 Καλησπέρα, θέλω να φτιάξω μια βάση δεδομένων για μια εφαρμογή αλλά κάτι δεν μου κάθεται καλά με το 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; Εσείς πως θα σχεδιάζατε μια τέτοια βαση; Ελπίζω να έγινα κατανοητός
Uberalles_gr Δημοσ. 24 Σεπτεμβρίου 2008 Δημοσ. 24 Σεπτεμβρίου 2008 Σίγουρα θα επηρεάσει την ταχύτητα των queries ένας πίνακας με πολλές εγγραφές και πολλά πεδία να έχει ο πίνακας. Π.χ. θα μπορούσες να σπάσεις τον κύριο σου πίνακα σε έναν πίνακα με κάποιες λεπτομέρειες για το κατάστημα. Πόσα columns πιστεύει θα έχει πίνακας με τα shops?
QSpec Δημοσ. 24 Σεπτεμβρίου 2008 Μέλος Δημοσ. 24 Σεπτεμβρίου 2008 Max 15. Από τα 15 τα 7 θα καλούνται σε κάθε προβολή του καταστήματος και άλλα 5 θα καλούνται εάν ο ιδιοκτήτης (user) έχει προσθέσει στοιχεία. Χμμ, θα μπορούσα να τον σπάσω σε έναν με τα στοιχεία που καλούνται πάντα και σε έναν με τα "προεραιτικά" στοιχεία.
alexandr0s Δημοσ. 25 Σεπτεμβρίου 2008 Δημοσ. 25 Σεπτεμβρίου 2008 Για τέτοιο αριθμό πεδίων δεν αξίζει να κάνεις τέτοιο διαχωρισμό (εκτός και αν τα πεδία είναι 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
Uberalles_gr Δημοσ. 25 Σεπτεμβρίου 2008 Δημοσ. 25 Σεπτεμβρίου 2008 Ναι πραγματικά επειδή είναι λίγα τα columns σίγουρα δεν θα έχεις κανένα πρόβλημα..
QSpec Δημοσ. 25 Σεπτεμβρίου 2008 Μέλος Δημοσ. 25 Σεπτεμβρίου 2008 Κατέληξα σε 3 πίνακες, έναν για τους users, έναν για τις πληροφορίες του καταστήματος και ένα για τις extra πληροφορίες. Αφού το μέγεθος δεν είναι μεγάλο ένας διαχωρισμός είναι αρκετός πιστεύω. Ευχαριστώ για τις απαντήσεις.
Προτεινόμενες αναρτήσεις
Αρχειοθετημένο
Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.