Εμφάνιση 1-5 από 5
  1. #1
    Εγγραφή
    24-09-2010
    Περιοχή
    Χαλκιδική
    Ηλικία
    28
    Μηνύματα
    743
    Downloads
    0
    Uploads
    0
    Τύπος
    ADSL
    Ταχύτητα
    24mbps
    ISP
    ΟΤΕ Conn-x
    Router
    ZTE ZXHN H108NS
    Στα Συννημένα αρχεία υπάρχει ένα PDF με το ER diagram μιας βάσης δεδομένων που σχεδίασα.

    Μπορείτε να το ρίξετε μια ματιά και να μου πείτε γνώμες; (πχ αν ακολουθώ σωστά τους κανόνες, μήπως η σχεδίαση μου γίνεται να απλοποιηθεί κτλ)

    Η βάση είναι ένα σύστημα διαχείρισης καταστημάτων "Κουρείων" και πελατών. Επιτρέπει στον διαχειρηστή να δημιουργεί κουρεία, μπαρμπέρηδες και δώρα, όπου τα δύο τελευταία σχετίζονται με τα κουρεία, δηλαδή σε ένα κουρείο υπάρχουν μπαρμπέρηδες που δουλεύουν σε αυτό και επίσης το κουρείο έχει κάποια δώρα που τα δίνει στους πελάτες όταν φτάσουν ένα συγκεκριμένο αριθμό σε μπόνους. Επίσης ο κάθε μπαρμπέρης έχει τις δικές του αυτόνομες ώρες δουλειάς (ωράριο) ανά εβδομάδα οι οποίες είναι πληρως επεξεργάσιμες από τον διαχειρηστή (Ο διαχειρηστής μπορεί να επιλέξει ακριβώς ποιες ώρες για κάθε μέρα τις εβδομάδας ο συγκεκριμένος μπαρμπερής θα δουλεύει);

    -Επίσης οι πελάτε μπορούν να κλείνουν ραντεβού.
    -Ο διαχειρηστής μπορεί να βάζει εξερέσεις στο ωράριο ενός συγκεκριμένουν μπαρμπέρη σε κάποια συγκεκριμένη ημερομηνία, πχ 2/2/220 να απενεργοποιήσει κάποιες από τις ώρες του ή και όλες για να του δώσει ρεπό.

    -Το σύστημα κρατήσεων, αυτόματα για μια συκεκριμένη ημερομηνία εντοπίζει με βάση τις εξερέσεις, τα ωράρια των μπαρπέρηδων και τις ήδη κρατημένες ώρες από άλλους πελάτες, τις ώρες που θα εμφανίσει στον πελάτη την ώρα που πάει να κλείσει ένα ραντεβου, ετσί ώστε ο πελάτης να βλέπει και να ξέρει ακριβώς μόνο ποιες ώρες είναι διαθέσημες για την συγκεκριμένη ημερομηνία.

    Αυτό το τελευταίο με παίδευσε πολύ (τι συσχετίσεις πρέπει να κάνω για να πετύχω τα σωστά relationships έτσι ώστε να μπορώ να κάνω τα σωστα queries).

    Πιστεύω σε αυτό το τελευταίο,όταν πάω να υπολοποιήσω τα queries θα μου βγεί η ψυχή, δεν έχω ξανά κάνει κάτι τόσο δύσκολο.
    Attached Thumbnails Attached Thumbnails alex-barber-shop.pdf  

    Τελευταία επεξεργασία από το μέλος babaliaris : 01-01-20 στις 22:18.

  2. #2
    Εγγραφή
    13-11-2011
    Περιοχή
    Χολαργός
    Ηλικία
    37
    Μηνύματα
    1.451
    Downloads
    1
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    24000 / 4500
    ISP
    Wind
    DSLAM
    Wind - ΧΟΛΑΡΓΟΣ
    Path Level
    Interleaved
    Καλημέρα,
    με μπερδεύει λίγο η περιγραφή των ωρών. Ενώ αναφέρεις ότι ο διαχειριστής θα βάζει συγκεκριμένες ώρες εργασίας μετά αναφέρεις και εξαιρέσεις. Αν βάζει συγκεκριμένες ώρες δεν χρειάζεται εξαιρέσεις γιατί απλά δεν θα τις βάζει εξαρχής. Μήπως ο διαχειριστής βάζει το πρόγραμμα και μετά κάνει εξαιρέσεις; Σε κάτι τέτοιο θα πρέπει να έχεις έναν extra πίνακα για τις αναθέσεις.

    Γιατί έχεις διαφορετικό πίνακα για ώρες και ημέρες;

    Επίσης οι κουρείς και τα ραντεβού είναι στον ίδιο πίνακα για την ώρα. Αυτό θα σου δημιουργήσει κάποια προβλήματα:
    - Θα πρέπει να έχεις δύο ξένα κλειδιά, ένα για κάθε πίνακα (Nullable). Αυτό θα δυσκολέψει λίγο τα ερωτήματα αλλά μπορεί να οδηγήσει και σε προβλήματα ακεραιότητας, καθώς η βάση δεν θα βγάλει error αν δεν βάλεις κανένα από τα δύο. Ή αν κάποια στιγμή κάνεις ένα λάθος και γράψεις σε λάθος στήλη δεν θα μπορέσεις να βρεις τι έγινε.
    - Αν χρειαστεί να βάλεις extra πληροφορία για το ραντεβού ή τον κουρέα, θα πρέπει να τα βάλεις όλα στον ίδιο πίνακα, που εννοιολογικά (και για την ψυχική σου υγεία αργότερα) δεν είναι και ότι καλύτερο
    - Η ημερομηνία στο ραντεβού είναι πάνω στο appointment ενώ για τον κουρέα είναι σε άλλο πίνακα. Άρα πρακτικά στον πίνακα με τις ώρες θα καταλήξεις να έχεις όλες τις ώρες/λεπτά της ημέρα, πράγμα που δεν έχει νόημα!

    Τα δώρα δίνονται σε συγκεκριμένα μαγαζιά μόνο ή σε συγκεκριμένο πελάτη άσχετα με το μαγαζί; Η σχέση του με το tb_shops υπονοεί μόνο σε συγκεκριμένα μαγαζιά.

    Για τον υπαλλήλους δεν έχεις βάλει κάποιο πεδίο που να δηλώνει αν είναι ενεργοί ή όχι. Έτσι αν φύγει κάποιος ή θα τον έχεις μόνιμα στη λίστα σου ή θα τον σβήσεις, μαζί με όλο το ιστορικό του (σαν εξαρτώμενα μέρη).

    Την διαχείριση των ωρών εργασίας θα την άλλαζα ως εξής:
    Στην απλή περίπτωση μπορείς να βάλεις τον διαχειριστή να καταχωρεί μόνο τις πραγματικές ημερομηνίες/ώρες έναρξης/λήξης εργασίας για κάθε υπάλληλο και το μαγαζί στο οποίο δούλεψε.

    Αν θέλεις να έχεις scheduling θα το άλλαζα ως εξής
    Ένας πίνακας με το schedule των εργασιών για κάθε υπάλληλο σε κάποιο κατάστημα
    Ένας πίνακας με εξαιρέσεις στο schedule με ημερομηνία ώρα διαφοροποίησης και το αν είναι επιπλέων ώρες, μείωση ή αλλαγή καταστήματος.
    Ένας πίνακας με ημερομηνία/ώρα έναρξης και λήξης με το id του υπαλλήλου και το μαγαζί στο οποίο δούλεψε, στο οποίο θα καταχωρούνται οι πραγματικές ώρες εργασίας.

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

    Τα ραντεβού, πιστεύω, πρέπει να πηγαίνουν κυρίως στα καταστήματα, και όχι στον κουρέα (εκτός αν υπάρχει απαίτηση να μπορείς να κλείνεις συγκεκριμένο κουρέα). Κλείνεις ραντεβού στο συγκεκριμένο κατάστημα και το σύστημα αναθέτει κουρέα ή επιλέγεις εσύ από τους διαθέσιμους του καταστήματος.

  3. #3
    Εγγραφή
    24-09-2010
    Περιοχή
    Χαλκιδική
    Ηλικία
    28
    Μηνύματα
    743
    Downloads
    0
    Uploads
    0
    Τύπος
    ADSL
    Ταχύτητα
    24mbps
    ISP
    ΟΤΕ Conn-x
    Router
    ZTE ZXHN H108NS
    Παράθεση Αρχικό μήνυμα από MitsakosGR Εμφάνιση μηνυμάτων
    Καλημέρα,
    με μπερδεύει λίγο η περιγραφή των ωρών. Ενώ αναφέρεις ότι ο διαχειριστής θα βάζει συγκεκριμένες ώρες εργασίας μετά αναφέρεις και εξαιρέσεις. Αν βάζει συγκεκριμένες ώρες δεν χρειάζεται εξαιρέσεις γιατί απλά δεν θα τις βάζει εξαρχής. Μήπως ο διαχειριστής βάζει το πρόγραμμα και μετά κάνει εξαιρέσεις; Σε κάτι τέτοιο θα πρέπει να έχεις έναν extra πίνακα για τις αναθέσεις.

    Γιατί έχεις διαφορετικό πίνακα για ώρες και ημέρες;

    Επίσης οι κουρείς και τα ραντεβού είναι στον ίδιο πίνακα για την ώρα. Αυτό θα σου δημιουργήσει κάποια προβλήματα:
    - Θα πρέπει να έχεις δύο ξένα κλειδιά, ένα για κάθε πίνακα (Nullable). Αυτό θα δυσκολέψει λίγο τα ερωτήματα αλλά μπορεί να οδηγήσει και σε προβλήματα ακεραιότητας, καθώς η βάση δεν θα βγάλει error αν δεν βάλεις κανένα από τα δύο. Ή αν κάποια στιγμή κάνεις ένα λάθος και γράψεις σε λάθος στήλη δεν θα μπορέσεις να βρεις τι έγινε.
    - Αν χρειαστεί να βάλεις extra πληροφορία για το ραντεβού ή τον κουρέα, θα πρέπει να τα βάλεις όλα στον ίδιο πίνακα, που εννοιολογικά (και για την ψυχική σου υγεία αργότερα) δεν είναι και ότι καλύτερο
    - Η ημερομηνία στο ραντεβού είναι πάνω στο appointment ενώ για τον κουρέα είναι σε άλλο πίνακα. Άρα πρακτικά στον πίνακα με τις ώρες θα καταλήξεις να έχεις όλες τις ώρες/λεπτά της ημέρα, πράγμα που δεν έχει νόημα!

    Τα δώρα δίνονται σε συγκεκριμένα μαγαζιά μόνο ή σε συγκεκριμένο πελάτη άσχετα με το μαγαζί; Η σχέση του με το tb_shops υπονοεί μόνο σε συγκεκριμένα μαγαζιά.

    Για τον υπαλλήλους δεν έχεις βάλει κάποιο πεδίο που να δηλώνει αν είναι ενεργοί ή όχι. Έτσι αν φύγει κάποιος ή θα τον έχεις μόνιμα στη λίστα σου ή θα τον σβήσεις, μαζί με όλο το ιστορικό του (σαν εξαρτώμενα μέρη).

    Την διαχείριση των ωρών εργασίας θα την άλλαζα ως εξής:
    Στην απλή περίπτωση μπορείς να βάλεις τον διαχειριστή να καταχωρεί μόνο τις πραγματικές ημερομηνίες/ώρες έναρξης/λήξης εργασίας για κάθε υπάλληλο και το μαγαζί στο οποίο δούλεψε.

    Αν θέλεις να έχεις scheduling θα το άλλαζα ως εξής
    Ένας πίνακας με το schedule των εργασιών για κάθε υπάλληλο σε κάποιο κατάστημα
    Ένας πίνακας με εξαιρέσεις στο schedule με ημερομηνία ώρα διαφοροποίησης και το αν είναι επιπλέων ώρες, μείωση ή αλλαγή καταστήματος.
    Ένας πίνακας με ημερομηνία/ώρα έναρξης και λήξης με το id του υπαλλήλου και το μαγαζί στο οποίο δούλεψε, στο οποίο θα καταχωρούνται οι πραγματικές ώρες εργασίας.

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

    Τα ραντεβού, πιστεύω, πρέπει να πηγαίνουν κυρίως στα καταστήματα, και όχι στον κουρέα (εκτός αν υπάρχει απαίτηση να μπορείς να κλείνεις συγκεκριμένο κουρέα). Κλείνεις ραντεβού στο συγκεκριμένο κατάστημα και το σύστημα αναθέτει κουρέα ή επιλέγεις εσύ από τους διαθέσιμους του καταστήματος.
    Ο λόγος που συσχετίζω barbers και appointments είναι διότι το κάθε appointment θα εξυπηρετεί έναν συγκεκριμένο πελάτη ο οποίος θα εξυπηρετείται από έναν συγκεκριμένο κουρέα σε μια ακριβώς συγκεκριμένη ώρα και σε έναν συγκεκριμένο μαγαζί.

    Ο λόγος που η κάθε ώρα είναι στο δικό της table είναι επειδή ο κάθε κουρέας πρέπει να έχει τα δικά του instances τις κάθε ώρας για κάθε μέρα της εμβομάδας και επίσης θα πρεπει να είναι διαφορετικά για κάθε μαγαζί (μπορεί να δουλεύει σε περισσότερα από ενα μαγαζιά ταυτόχρανα αρκεί να μην συμπίπτουν οι ώρες.) Με αυτόν τον τρόπο, ο διαχειριστής μπορεί να επιλέγει ακριβώς ποιες ώρες τις εβδομάδας για κάθε μέρα ξεχωριστά θα δουλεύει ο συγκεκριμένος κουρέας.

    Η παραπάνω πληροφορία χρησιμοποιείτε για να ξέρω τις διαθέσιμες ώρες που θα εμφανίζω στον χρήστη όταν πάει να κλείσει ραντεβού.
    Το θέμα είναι ότι πρέπει επίσης για μια συγκεκριμένη ημερομηνία να ξέρω ποιες ώρες είναι ήδη κλεισμένες από άλλους πελάτες έτσι ώστε όταν χρήστης πάει να κλείσει ραντεβού να μην του τις εμφανίζω. Αυτήν την δουλειά κάνει η συσχέτιση του tb_appointments με τον tb_hours. [Edited]: Από ότι παρατήρησα στο παρακάτω query τελικά από τα joins ηδη έχω τις ώρες μέσα άρα δεν χρηάζεται το fereign key στον tb_appointments. Το θέμα είναι ότι πρωτού κανω αυτό το query δεν το εχα σκεφτεί. Αλλά γενικά προσπαθώ να ακολουθώ τους κανόνες που έμαθα στην σχολή, έτσι ώστε να φτιάχνω συσχετίσεις πρωτού καν σκεφτώ τα queries.

    Πρώτα θα γίνεται το query για να πάρω όλες τις διαθέσιμες ώρες από όλους τους κουρείς για την συγκεκριμένει μέρα και μαγαζί στο οποίο θέλει να κλείσει ραντεβού ο πελάτης.
    Στην συνέχεια, θα φιλτρτάρω αυτό το αποτέλεσμα με τον tb_apointment έτσι ώστε να πετάξω έξω τις ώρες που είναι ήδη κλεισμένες.
    Και ότι μένει, το δείχνω στον χρήστη.

    1) Για να πετύχω το παραπάνω πρέπει να κάνω
    Κώδικας:
    tb_barbers JOIN tb_barbers_hours_relation JOIN tb_days JOIN tb_shops JOIN tb_appointments
    για να πάρω όλες τις ώρες που δουλεύουν όλοι οι κουρείς σε μία συγκεκριμένει μέρα σε ένα συγκεκριμένο μαγαζί και δεν έχουν ήδη κρατηθεί από άλλους πελάτες.

    Τα υπόλοιπα που είπες για το είδος (λούσιμο, αντρικό κούρεμα, παιδικό κτλ) ναι δεν τα έχω βάλει άλλα σκόπευα να τα κάνω. Τώρα για το πόσο χρόνο κρατάει το καθένα δεν με ενδιαφέρει, ο πελάτη είπε ότι η κάθε υπηρεσία κρατάει περίπου 20 λεπτά και θέλει το ωράριο (πρόγραμμα) να χωρίζεται ανά 20 λεπτά η ανά 30, θα το αποφασίσει αυτός. Το σιγουρό είναι ότι θέλει το πρόγραμμα να διαιρείται σε ίσα διαστήματα.
    Τελευταία επεξεργασία από το μέλος babaliaris : 02-01-20 στις 20:50.

  4. #4
    Εγγραφή
    13-11-2011
    Περιοχή
    Χολαργός
    Ηλικία
    37
    Μηνύματα
    1.451
    Downloads
    1
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    24000 / 4500
    ISP
    Wind
    DSLAM
    Wind - ΧΟΛΑΡΓΟΣ
    Path Level
    Interleaved
    Παράθεση Αρχικό μήνυμα από babaliaris Εμφάνιση μηνυμάτων
    Ο λόγος που συσχετίζω barbers και appointments είναι διότι το κάθε appointment θα εξυπηρετεί έναν συγκεκριμένο πελάτη ο οποίος θα εξυπηρετείται από έναν συγκεκριμένο κουρέα σε μια ακριβώς συγκεκριμένη ώρα και σε έναν συγκεκριμένο μαγαζί.

    Ο λόγος που η κάθε ώρα είναι στο δικό της table είναι επειδή ο κάθε κουρέας πρέπει να έχει τα δικά του instances τις κάθε ώρας για κάθε μέρα της εμβομάδας και επίσης θα πρεπει να είναι διαφορετικά για κάθε μαγαζί (μπορεί να δουλεύει σε περισσότερα από ενα μαγαζιά ταυτόχρανα αρκεί να μην συμπίπτουν οι ώρες.) Με αυτόν τον τρόπο, ο διαχειριστής μπορεί να επιλέγει ακριβώς ποιες ώρες τις εβδομάδας για κάθε μέρα ξεχωριστά θα δουλεύει ο συγκεκριμένος κουρέας.

    Η παραπάνω πληροφορία χρησιμοποιείτε για να ξέρω τις διαθέσιμες ώρες που θα εμφανίζω στον χρήστη όταν πάει να κλείσει ραντεβού.
    Το θέμα είναι ότι πρέπει επίσης για μια συγκεκριμένη ημερομηνία να ξέρω ποιες ώρες είναι ήδη κλεισμένες από άλλους πελάτες έτσι ώστε όταν χρήστης πάει να κλείσει ραντεβού να μην του τις εμφανίζω. Αυτήν την δουλειά κάνει η συσχέτιση του tb_appointments με τον tb_hours. [Edited]: Από ότι παρατήρησα στο παρακάτω query τελικά από τα joins ηδη έχω τις ώρες μέσα άρα δεν χρηάζεται το fereign key στον tb_appointments. Το θέμα είναι ότι πρωτού κανω αυτό το query δεν το εχα σκεφτεί. Αλλά γενικά προσπαθώ να ακολουθώ τους κανόνες που έμαθα στην σχολή, έτσι ώστε να φτιάχνω συσχετίσεις πρωτού καν σκεφτώ τα queries.

    Πρώτα θα γίνεται το query για να πάρω όλες τις διαθέσιμες ώρες από όλους τους κουρείς για την συγκεκριμένει μέρα και μαγαζί στο οποίο θέλει να κλείσει ραντεβού ο πελάτης.
    Στην συνέχεια, θα φιλτρτάρω αυτό το αποτέλεσμα με τον tb_apointment έτσι ώστε να πετάξω έξω τις ώρες που είναι ήδη κλεισμένες.
    Και ότι μένει, το δείχνω στον χρήστη.

    1) Για να πετύχω το παραπάνω πρέπει να κάνω
    Κώδικας:
    tb_barbers JOIN tb_barbers_hours_relation JOIN tb_days JOIN tb_shops JOIN tb_appointments
    για να πάρω όλες τις ώρες που δουλεύουν όλοι οι κουρείς σε μία συγκεκριμένει μέρα σε ένα συγκεκριμένο μαγαζί και δεν έχουν ήδη κρατηθεί από άλλους πελάτες.

    Τα υπόλοιπα που είπες για το είδος (λούσιμο, αντρικό κούρεμα, παιδικό κτλ) ναι δεν τα έχω βάλει άλλα σκόπευα να τα κάνω. Τώρα για το πόσο χρόνο κρατάει το καθένα δεν με ενδιαφέρει, ο πελάτη είπε ότι η κάθε υπηρεσία κρατάει περίπου 20 λεπτά και θέλει το ωράριο (πρόγραμμα) να χωρίζεται ανά 20 λεπτά η ανά 30, θα το αποφασίσει αυτός. Το σιγουρό είναι ότι θέλει το πρόγραμμα να διαιρείται σε ίσα διαστήματα.
    To 'JOIN tb_barbers_hours_relation JOIN tb_days JOIN tb_shops' είναι ένα παραπάνω join που μπορείς να το αποφύγεις. Απλά εννοποιείς το hours/days σε έναν πίνακα. Η επίδρασή του στο μέγεθος της βάσης είναι αμελητέα σε σχέση με την απόδοσή του λόγω του join.

    Στις βάσεις δεν υπάρχει απολύτως σωστό και λάθος. Απλά μερικές φορές στην προσπάθεια να το κάνουμε όσο το δυνατόν καλύτερο, με βάση τους κανόνες, καταλήγουμε να το υπεραναλύουμε και να το κάνουμε πολύ δύσχρηστο. Πρέπει να βρεις μία "χρυσή τομή" ανάμεσα στο τι είναι σωστό για εξοικονόμηση χώρου και τι είναι πιο αποδοτικό για να τρέχεις πιο έυκολα τα ερωτήματά σου. Πολλές φορές αυτά τα δύο είναι αντίθετα μεταξύ τους οπότε πρέπει να αξιολογήσεις τι θα σε βολεύει καλύτερα στην υλοποίηση σε σχέση με τον χώρο που εξοικονομείς.

  5. #5
    Εγγραφή
    24-09-2010
    Περιοχή
    Χαλκιδική
    Ηλικία
    28
    Μηνύματα
    743
    Downloads
    0
    Uploads
    0
    Τύπος
    ADSL
    Ταχύτητα
    24mbps
    ISP
    ΟΤΕ Conn-x
    Router
    ZTE ZXHN H108NS
    Παράθεση Αρχικό μήνυμα από MitsakosGR Εμφάνιση μηνυμάτων
    To 'JOIN tb_barbers_hours_relation JOIN tb_days JOIN tb_shops' είναι ένα παραπάνω join που μπορείς να το αποφύγεις. Απλά εννοποιείς το hours/days σε έναν πίνακα. Η επίδρασή του στο μέγεθος της βάσης είναι αμελητέα σε σχέση με την απόδοσή του λόγω του join.

    Στις βάσεις δεν υπάρχει απολύτως σωστό και λάθος. Απλά μερικές φορές στην προσπάθεια να το κάνουμε όσο το δυνατόν καλύτερο, με βάση τους κανόνες, καταλήγουμε να το υπεραναλύουμε και να το κάνουμε πολύ δύσχρηστο. Πρέπει να βρεις μία "χρυσή τομή" ανάμεσα στο τι είναι σωστό για εξοικονόμηση χώρου και τι είναι πιο αποδοτικό για να τρέχεις πιο έυκολα τα ερωτήματά σου. Πολλές φορές αυτά τα δύο είναι αντίθετα μεταξύ τους οπότε πρέπει να αξιολογήσεις τι θα σε βολεύει καλύτερα στην υλοποίηση σε σχέση με τον χώρο που εξοικονομείς.
    Σκεφτόμουν ότι αν τα βάλω σε έναν πίνακα τότε αν πχ η κάθε μέρα έχει πχ 10 υποδιαιρέσεις τις ώρας (8, 8:20, 8:40 κτλ) και το εβδομαδιαίο πρόγραμμα έχει 5 μέρες, τότε το κάθε μαγαζί θα έχει 5*10 = 50 καταχαρώσεις στον πίνακα tb_schedule και θα τρώει πολύ χώρο, αλλά τελικά έχεις δίκαιο. Έτσι όπως το έχω φτιάξει τώρα, πάλι 50 θα είναι η καταχωρήσεις συνολικά, 5 στον tb_days και tb_hours 10*5 =50 και αν τα προσθέσω βγαίνουν 55 σύνολο λολ, αυτό είναι χειρότερο και στο θέμα χώρου αλλά και στο θέμα ταχύτητας των joins

    - - - Updated - - -

    Έκανα μερικές βελτιώσεις. Σκέφτηκα αρκετά πως να κάνω τα schedules και τα exceptions και τελικά κατέληξα να φτιάξω ξεχωριστούς πίνακες. Τα exceptions στην ουσία είναι schedules τα οποία ισχύουν μόνο για μια συγκεκριμένη ημερομηνία. Είναι στην ουσία σαν να κάνω override ολόκληρο το πρόγραμμα για ένα συγκεκριμένο μαγαζί για μια συγκεκριμένη ημερομηνία.

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

    Γιατί το κάνω αυτό; Γιατί μπορεί ο διαχειρηστής μια μέρα να κλείσει το μαγαζί και να πάρει ρεπό ή να δώσει ρεπό σε κάποιον κομμωτή ή μπορεί να δώσει μόνο συγκεκριμένες ώρες ρεπό για εκείνη την ημέρα .
    Attached Thumbnails Attached Thumbnails alex-barber-shop.pdf  

    Τελευταία επεξεργασία από το μέλος babaliaris : 03-01-20 στις 02:18.

Bookmarks

Bookmarks

Δικαιώματα - Επιλογές

  • Δεν μπορείτε να δημοσιεύσετε νέα θέματα
  • Δεν μπορείτε να δημοσιεύσετε νέα μηνύματα
  • Δεν μπορείτε να αναρτήσετε συνημμένα
  • Δεν μπορείτε να επεξεργαστείτε τα μηνύματα σας
  •  
  • Τα BB code είναι σε λειτουργία
  • Τα Smilies είναι σε λειτουργία
  • Το [IMG] είναι σε λειτουργία
  • Το [VIDEO] είναι σε λειτουργία
  • Το HTML είναι εκτός λειτουργίας