πια είναι η καλύτερη σχεδίαση για eshop

Σε αυτή την περιοχή μπορείτε να βρείτε ή να αναζητήσετε πληροφορίες σχετικές με την PHP

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

Απάντηση
Άβαταρ μέλους
Khronos
Δημοσιεύσεις: 754
Εγγραφή: 11 Δεκ 2006 14:43
Τοποθεσία: Ηράκλειο

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από Khronos » 31 Ιούλ 2013 15:24

geomagas έγραψε:Εδώ θα χρειαστείς μία συσχέτηση του τύπου (product_id,feature,value) όπου για την περίπτωση της εγγύησης ενός προϊόντος θα έχεις μία πλειάδα πχ (16538,'warranty','3 years').
Αφού η εγγύηση είναι χαρακτηριστικό (attribute) ενός προϊόντος γιατί να μπει σε ξεχωριστό πίνακα και όχι σαν attributes -> hasWarranty(boolean), warranty(string) διευκολύνοντας το reporting κτλ?

Αν μπορείς δώσε και άλλα παραδείγματα για το διαχωρισμό feature - atrribute για να το καταλάβουμε.

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από geomagas » 31 Ιούλ 2013 16:59

Khronos έγραψε:
geomagas έγραψε:Εδώ θα χρειαστείς μία συσχέτηση του τύπου (product_id,feature,value) όπου για την περίπτωση της εγγύησης ενός προϊόντος θα έχεις μία πλειάδα πχ (16538,'warranty','3 years').
Αφού η εγγύηση είναι χαρακτηριστικό (attribute) ενός προϊόντος
Εγώ δεν είπα αυτό, είπα ότι είναι feature. Σύμφωνα με την (αυθαίρετη, αλλά για χάρη του παραδείγματος) υπόθεση ότι κάποια προϊόντα (μεμονωμένα αντικείμενα) δίνονται με εγγύηση και κάποια όχι, ανεξάρτητα από το είδος τους (κλάση).
Khronos έγραψε: γιατί να μπει σε ξεχωριστό πίνακα και όχι σαν attributes -> hasWarranty(boolean), warranty(string) διευκολύνοντας το reporting κτλ?
Οκ, κανένα πρόβλημα, είναι μία άλλη υλοποίηση. Όμως, για να το κάνεις αυτό, έχεις αποφασίσει ότι θα έχεις ένα attribute, το hasWarranty, και ένα άλλο εξαρτώμενο από το πρώτο, το warranty. Δηλαδή, έχεις προαποφασίσει να τα δεις σαν attributes και όχι features, για τους δικούς σου λόγους.
Όμως:
- Αν το 90% των προϊόντων δίνεται χωρίς εγγύηση, ο πίνακάς σου αρχίζει να γίνεται "αραιός".
- Πως εξασφαλίζεις ότι, σε μία πλειάδα με hasWarranty==False, το πεδίο warranty θα είναι οπωσδήποτε null (και το αντίθετο); Μιλώ για το επίπεδο της ΒΔ.
- Αν η συσχέτιση του προϊόντος με συγκεκριμένο feature είναι M:N, ενώ με άλλο όχι;
Το επιχείρημα για το reporting θα μου επιτρέψεις να μην το λάβω καθόλου υπόψιν, καθώς μιλάμε για τη σχεδίαση της ΒΔ. Με δεδομένη, έτοιμη βάση, συζητάμε για interfaces και αλληλεπίδραση. Αλλιώς, απλά αποσπάς την προσοχή σου από το πρόβλημα.
Khronos έγραψε: Αν μπορείς δώσε και άλλα παραδείγματα για το διαχωρισμό feature - atrribute για να το καταλάβουμε.
Ναι, βέβαια.

Το Wordpress έχει, στη βασική του εγκατάσταση δυο τύπους περιεχομένου (content): page και article. A page is-a content & An article is-a content. Λοιπόν:
- Η ημερομηνία δημοσίευσης και ο τίτλος είναι attributes του content (όλοι οι τύποι content έχουν υποχρεωτικά και τα δύο)
- Η κάθε σελίδα έχει το πολύ μία πατρική σελίδα (parent). Attribute του page.
- Το κάθε άρθρο ανήκει σε 0 έως Ν κατηγορίες. Attribute (με πολλές τιμές) του article.
- Κάθε content έχει 0 έως Ν αυθαίρετα metatags. Feature του content.

Άλλο:
Ταξινομείς το "ζωικό βασίλειο" σε: Ψάρι is-a ζώο, Θηλαστικό is-a ζώο, Πτηνό is-a ζώο, Σκύλος is-a Θηλαστικό, Γάτα is-a Θηλαστικό, Κότα is-a Πτηνό, Παπαγάλος is-a Πτηνό, μπαρμπούνι is-a Ψάρι κ.ο.κ
Κάποια στιγμή θέλεις να εισάγεις την έννοια του "κατοικιδίου". Ένα κατοικίδιο έχει ιδιοκτήτη, αλλά μπορεί να ανήκει σε οποιαδήποτε κλάση από τις παραπάνω.
Ε, λοιπόν, ο ιδιοκτήτης είναι ένα feature του Ζώου, και όχι attribute. Είναι αυθαίρετη ιδιότητα, με την έννοια ότι δεν είναι καθόλου υποχρεωτικό να υλοποιηθεί σε κανένα επίπεδο της ταξινόμησης.

Άβαταρ μέλους
Khronos
Δημοσιεύσεις: 754
Εγγραφή: 11 Δεκ 2006 14:43
Τοποθεσία: Ηράκλειο

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από Khronos » 01 Αύγ 2013 09:51

Συμφωνώ 100% με τα παραπάνω (τα της σχεδίασης της ΒΔ). Και πολύ κατανοητά τα παραδείγματα σου.
Και ξαναπάω σε αυτό που ρώτησε και ο Lykos22.

Σε πραγματικές συνθήκες θα το υλοποιούσες έτσι? Θα είχες διαφορετικό σχήμα για κάθε περίπτωση (πχ. eshop) και κατά συνέπεια διαφορετικό κώδικα?

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από geomagas » 01 Αύγ 2013 10:16

Khronos έγραψε:Σε πραγματικές συνθήκες θα το υλοποιούσες έτσι?
Σε πραγματικές συνθήκες, στο 90% των περιπτώσεων, το έχω υλοποιήσει έτσι. Μάλιστα, στην πράξη θα δεις ότι, όσο η εφαρμογή, άρα και η ΒΔ, είναι μεγαλύτερη (από πλευράς metadata, όχι απαραίτητα data) τόσο περισσότερο "συμφέρει" αυτό το σχήμα.
Μία μεγάλη εφαρμογή, που την αναπτύσσει μία ομάδα από developers, τελικά καταλήγει να αποτελείται από έναν αριθμό σχεδόν διακριτών υποσυστημάτων. Αυτό τελικά είναι σκόπιμο να απεικονιστεί και στο διαχωρισμό των αντικειμένων της ΒΔ.
Φαντάσου να "διαχειριζόμαστε" (=τσακωνόμαστε) όλοι τον ίδιο πίνακα... Το έχω δει, και δεν είναι καθόλου παραγωγικό.
Khronos έγραψε: Θα είχες διαφορετικό σχήμα για κάθε περίπτωση (πχ. eshop) και κατά συνέπεια διαφορετικό κώδικα?
Δεν το πολυκατάλαβα αυτό και δεν ξέρω αν σου απαντώ ακριβώς στην ερώτησή σου.
Το τελικό σχήμα είναι ένα. Και γιατί να έχεις διαφορετικό κώδικα; Εννοείς για κάθε κλάση; Μα αυτό είναι το νόημα: Κάθε κλάση να έχει διαφορετικά πεδία/μεθόδους μόνο στο βαθμό που διαφέρει από τα "αδέρφια" της (siblings). Τελικά θα δεις ότι ο κώδικας που θα γράψεις είναι πολύ λιγότερος από όσο περίμενες, και πιο επαναχρησιμοποιούμενος (αν και, σίγουρα περισσότερος από τη μη-OOP προσέγγιση...)

Άβαταρ μέλους
Khronos
Δημοσιεύσεις: 754
Εγγραφή: 11 Δεκ 2006 14:43
Τοποθεσία: Ηράκλειο

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από Khronos » 01 Αύγ 2013 10:28

geomagas έγραψε:Δεν το πολυκατάλαβα αυτό και δεν ξέρω αν σου απαντώ ακριβώς στην ερώτησή σου.
Εννοώ ότι θα καταλήξεις να έχεις, ανάλογα με το τι πουλάει το eshop, ξεχωριστούς πίνακες για products όπως computers, monitors, beers κτλ.

Ρωτάω γιατί αν και είχα ανοίξει το θέμα πριν τόσο καιρό, δεν είχα καταλήξει ακόμα με ποιο τρόπο θα πήγαινα.

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από geomagas » 01 Αύγ 2013 10:49

Δεν υπάρχει κανένας νόμος που να σου λέει (και καμία σκοπιμότητα) να φτάσεις στο έσχατο επίπεδο ανάλυσης.
Όπως είπα και μερικά posts πριν, πρώτα θα πρέπει να αποφασίσεις τι θεωρείς attribute (και γενικότερα ξεχωριστή κλάση) σύμφωνα με τις ανάγκες της εφαρμογής σου. Και με το "ανάγκες" εννοώ ανάγκες λειτουργίας αλλά και ανάπτυξης/συντήρησης.

Δεν θα έφτανα στο σημείο να ορίσω κλάσεις που θα περιείχαν 1-2 πεδία, και μάλιστα μικρής σημασίας (magnitude) για την εφαρμογή. Αυτό, μόνο κόστος διαχείρισης/ανάπτυξης έχει, και τίποτε άλλο.

Στη γενικότερη περίπτωση, και μιας που μιλάμε για (e-)shop φαντάζομαι με την ευρεία έννοια, θα διαχώριζα τα Αγαθά σε Προϊόντα και Υπηρεσίες. Μέχρι εκεί. Αν δεν είναι πολύ σημαντικό, όλα τα άλλα μπορούν να είναι features. Και βέβαια, οτιδήποτε λιγότερο από αυτό είναι flat.

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

Η λέξη-κλειδί είναι Χρυσή Τομή.

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

Άβαταρ μέλους
Khronos
Δημοσιεύσεις: 754
Εγγραφή: 11 Δεκ 2006 14:43
Τοποθεσία: Ηράκλειο

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από Khronos » 01 Αύγ 2013 11:12

Έτσι όπως τα είπες ακούγονται πολύ λογικά!
Τώρα μένει να δούμε πώς θα το υλοποιήσει ο Lykos22.

Άβαταρ μέλους
jpk
Δημοσιεύσεις: 441
Εγγραφή: 09 Μαρ 2011 21:17

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από jpk » 03 Αύγ 2013 00:51

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

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

Φυσικά και έχω αναπτύξει ένα κεντρικό λογισμικό πάνω στο οποίο κινούμαστε , αλλά το μέγεθος της λογικής κίνησης ανά πελάτη τόσο στην δόμηση όσο και στην υλοποίηση διαφέρει. Πριν από κάποιους μήνες θα έλεγα ότι μετά από κάποιες δεκάδες e-shops είχα βρει ένα κεντρικό πίνακα προϊόντων ,ένα πίνακα παραμετροποιημένων πεδίων ανά κατηγορία που εμπεριέχει τον τύπο τους, και ένα ακόμα αν ο τύπος τους είναι επιλογής, και φυσικά ανά πελάτη έδινες την δυνατότητα να τα αλλάζει ο admin ή μόνο ο super admin (δηλαδή εμείς).

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

geomagas
Δημοσιεύσεις: 667
Εγγραφή: 06 Απρ 2013 13:36
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

πια είναι η καλύτερη σχεδίαση για eshop

Δημοσίευση από geomagas » 03 Αύγ 2013 12:30

Προσπαθώ να αποκωδικοποιήσω τα επιχειρήματά σου, αλλά:

- Μιλάς για αρχιτεκτονικές, ενώ μιλούσαμε για μεθόδους.
Η αρχιτεκτονική είναι μία έννοια που διέπει οριζόντια την τελική φάση της υλοποίησης, τόσο στο s/w όσο και στο h/w. Και είναι πολύ γενική, με την έννοια ότι μπορεί να αφορά πολλά πράγματα.
Επίσης, πως μπορεί να "υπάρχει μόνο μία" και συγχρόνως "μία μίξη"; Το ένα δεν αναιρεί το άλλο;

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

- Τίποτα δεν "τα λύνει όλα". Το μόνο που, τελικά, δεν υπάρχει είναι η "πανάκεια".

Καταλαβαίνω ότι έχετε φτιάξει το δικό σας framework και ότι έχετε ασχοληθεί πολύ με το θέμα, ειδικά των e-shops, αλλά κι εσύ καταλαβαίνεις ότι, κάτι στο οποίο εκ των πραγμάτων κάποιος δεν μπορεί να τοποθετηθεί, δεν αποτελεί και επιχείρημα...

Ένα link για την παλιότερη τοποθέτησή σου θα ήταν χρήσιμο, για να αποκτήσουμε καλύτερη εικόνα για το δικό σου τρόπο σκέψης. edit: Εκτός αν εννοείς "αυτό το θέμα"=="αυτό το topic", οπότε οκ.

Απάντηση

Επιστροφή στο “PHP Προγραμματισμός”

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

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