Συζήτηση για σχεδιασμό βάσης που θα παρέχει στατιστικά στοιχεία πωλήσεων

Συζητήσεις για την βάση δεδομένων MySQL και το phpMyAdmin

Συντονιστές: WebDev Moderators, Super-Moderators

Απάντηση
alou
Script Master
Δημοσιεύσεις: 1374
Εγγραφή: 24 Αύγ 2007 19:52
Επικοινωνία:

Συζήτηση για σχεδιασμό βάσης που θα παρέχει στατιστικά στοιχεία πωλήσεων

Δημοσίευση από alou » 16 Ιούλ 2014 23:52

geomagas έγραψε: Συνήθως αναφερόμαστε στο pivoting ως έναν μετασχηματισμό του dataset για την παραγωγή συγκεντρωτικών στοιχείων. Στη γενική περίπτωση η διαδικασία περιλαμβάνει τη μετατροπή μίας στήλης σε πολλές, με τις distinct τιμές της να μετατρέπονται σε fields. Πχ δες εδώ, ή εδώ που η υλοποίηση στο fiddle της απάντησης είναι πιο "ψαγμένη" ;).
Μάλιστα... thanks για τη διευκρίνηση, ευκαιρία για λίγη μελέτη!
geomagas έγραψε:
Εσύ, σε κάθε περίπτωση, μετά την εισαγωγή έχεις barcode, δεν είναι έτσι;
Το οποίο έχεις ούτως ή άλλως στη βάση σου, αλλιώς δεν μπορείς να κάνεις τίποτα.
Οπότε, το δίλημμα είναι αν θα κρατήσεις το ίδιο το barcode σαν pk ή θα έχεις ένα δικό σου, με αντιστοιχία 1:1 με το barcode. Εγώ θα κρατούσα το barcode.
alou έγραψε:Δεν έχει νόημα η απάντηση για την ώρα καθώς οι λεπτομέρειες της εισαγωγής στοιχείων ακόμα εκκρεμούν + υπάρχουν κάποια μπερδέματα που αρχίζουν να εμφανίζονται, πχ προϊόντα με διπλά barcodes κ.ά. που μπορεί να οδηγήσουν αναγκαστικά και όχι για καλύτερο σε κάποια συγκεκριμένη λύση.
Θέλεις να πεις ότι το ίδιο ακριβώς προϊόν εμφανίζεται με πολλά διαφορετικά barcodes; Γιατί αν είναι έτσι, πάει περίπατο η αντιστοιχία 1:1 που είπαμε παραπάνω. Οπότε:
- είτε κρατάς το barcode σαν pk και αναγκαστικά έχεις πολλά instances για το ίδιο προϊόν
- είτε έχεις ένα δικό σου id στον product αλλά χρειάζεσαι έναν δεύτερο πίνακα (barcode pk, product fk[product.code]) για την αντιστοίχιση.
Το θέμα με τα διπλά barcodes δεν ήταν τόσο αναπάντεχο, πχ ένα προϊόν αλλάζει barcode γιατί βγαίνει για Χ χρονικό διάστημα με δώρο ένα δείγμα από κάτι άλλο ή για οποιοδήποτε άλλο promo.

Το θέμα είναι αν το θεωρείς ίδιο προϊόν ή άλλη οντότητα, όπως είπες και εσύ.
Στο παραπάνω παράδειγμα θα ήταν λογικό ίσως το πρώτο (ίδιο προϊόν) αλλά είναι πολύ πιθανό να προκύψει και κάτι λιγότερο λογικό σε πολλαπλά barcodes (πχ άλλαξε διανομέα - πολύ πιθανό σενάριο) οπότε αποκλείεται να πρέπει να θεωρηθεί άλλη οντότητα.

Οπότε μάλλον το πιο σωστό και future (αλλά και feature*)-proof θα ήταν να πας σε ένα δικό σου κωδικό ως product id και ένα επιπλέον πίνακα (όπως είπες και συ) και έχεις να λύσεις και το πρόβλημα της ανεύρεσης πολλαπλών barcodes.

*Σε αυτή την περίπτωση βάζεις και μια άλλη διάσταση, στατιστικών των επιμέρους barcode των προϊόντων ή στατιστικών των promo barcodes κλπ κλπ που πιθανώς θα ήταν χρήσιμο...

Απάντηση

Επιστροφή στο “MySQL”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 1 επισκέπτης