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

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

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

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

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

Δημοσίευση από Khronos » 26 Μάιος 2011 14:29

Κάνοντας έρευνα για να ξεκινήσω να φτιάχνω και γω κάτι παρόμοιο έπεσα σε αυτό το άρθρο.

http://stackoverflow.com/questions/6957 ... ers#695860

Είμαι ανάμεσα σε class table inheritance και eav.
Εσείς με ποιο design θα πηγαίνατε και γιατί?

Άβαταρ μέλους
dva_dev
Script Master
Δημοσιεύσεις: 3790
Εγγραφή: 16 Σεπ 2005 01:32
Επικοινωνία:

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

Δημοσίευση από dva_dev » 26 Μάιος 2011 18:32

To καλό με το class table inheritance είναι ότι θα φτιάξεις τη βάση σου, και θα παίρνεις τα προϊόντα σου σε χρόνο μηδέν.
Το καλό με το eav είναι ότι αφού φτιάξεις τη βάση σου μπορείς και ξεκινήσεις να πουλάς βελόνες και να φτάσεις να πουλάς μέχρι διαστημόπλοια και πλανήτες, πιθανώς χωρίς να χρειαστεί να ξανακούσεις τις λέξεις βάση δεδομένων.

Εσύ περίπου που κυμαίνεσαι; Ξέρεις τι προϊόντα έχεις και τι θα πουλάς και σε νοιάζει να έρχονται όσο το δυνατόν πιο γρήγορα; ή δεν έχεις ιδέα και θέλεις να μπορείς να πουλάς τα πάντα (μα τα πάντα);

Για να έχεις αποκλείσει κάποιες από τις άλλες επιλογές που αναφέρονται στο άρθρο κάτι θα έχεις στο μυαλό σου... Γιατί τα απέκλεισες;

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

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

Δημοσίευση από Khronos » 26 Μάιος 2011 19:30

Καταρχήν θέλω να το φτιάξω για εκπαιδευτικούς λόγους οπότε δεν έχω ιδέα τι προϊόντα μπορεί να υπάρχουν. :P

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

Επίσης αν θέλω να παίρνω την τιμή κάποιου attribute από έναν άλλο πίνακα στη βάση, γίνεται με το eav?

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

Αν μπορείς να μου δώσεις μερικά παραδείγματα για τον τρόπο υλοποίησης θα με βοηθούσε πολύ!

pimpogio
Δημοσιεύσεις: 1080
Εγγραφή: 28 Δεκ 2010 14:08

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

Δημοσίευση από pimpogio » 30 Μάιος 2011 02:39

θες abstraction -> eav
θες ταχυτητα και συγκεριμενα πραγματα -> inheritance

στο eav δεν μπορεις να εκμεταλευτεις τις δυνατοτητες
μιας σχεσιακης βασης στο επακρο καθως δεν μπορεις να τρεξεις αποδοτικα queries με το eav κανεις την db σαν απλο stogare...

Εγω επελεξα το inheritance...
καθως το αλλο το εχουνε ολα τα generic eshop cms
και ειναι ενας απο τους βασικους λογους που σερνονται
βλεπε magento που εχει eav και διαλυει το server...

H θεωρια των σχεσιακων βασεων λεει το inheritance με normalization.

Στην πραξη τωρα το inheritance επειδη εκ των προτερων γνωστο το ευρος των ιδιοτητων
στο 99% των περιπτωσεων και επειδη ο δισκος δεν ακριβος αλλα η ram kai η cpu ειναι
παλι το inheritance κερδιζει...

Το eav ειναι κατα τη γνωμη μου για καποιον που δεν εχει ιδεα απο προγραμματισμο
και ουτε θα ασχοληθει να πείραξει την εφαρμογη...
για κάποιον που θελει fast food.

Κατα περιπτωση τα ζυγιζεις και πρατεις...
σε δικο μου παντως eshop που θα το δουλευα εγω θα διαλεγα με κλειστα ματια inheritance
για λογους ταχυτητας debugging ktlp

οσο για το multilanguage ειναι μανικι και αυξανει κατακορυφα τη δυσκολια στην διαχειρηση

Αν πας με το eav μπορεις να δεις την database του magento που δουλευει ετσι..

Άβαταρ μέλους
korgr
Honorary Member
Δημοσιεύσεις: 5067
Εγγραφή: 07 Οκτ 2008 18:30
Τοποθεσία: Corinth
Επικοινωνία:

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

Δημοσίευση από korgr » 30 Μάιος 2011 09:36

pimpogio μερικές φορές τα κείμενά σου με κάνουν να αναρωτιέμαι:
«Που πάω ο Καραμήτρος!» :o

Από την άλλη σκέφτομαι πως για να δημιουργώ κι εγώ λειτουργικά e-shops, κάπου μέσα τους θα έχουν κι αυτά όλες αυτές τις άγνωστες λέξεις που διαβάζω :)

pimpogio
Δημοσιεύσεις: 1080
Εγγραφή: 28 Δεκ 2010 14:08

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

Δημοσίευση από pimpogio » 30 Μάιος 2011 17:10

σιγουρα κατι απο αυτα εχεις κανει και εσυ στο eshop σου
αν αντι eav να το πεις και ευελικτο μοντελο η οχι στηλες αλλα γραμμες / κληρονομικοτητα και οπως θες δεν κανει διαφορα ενας ορος ειναι απλα...
Μην κολας στον ορο..

http://en.wikipedia.org/wiki/Entity-att ... alue_model
http://en.wikipedia.org/wiki/Inheritanc ... ramming%29

σχεσιακο παραδειγμα != eav

τα ετοιμα cms επειδη τα εχουνε κανει να ειναι γενικης χρησης ειναι ολα με eav και ειναι και
1ας βασικος λογος που σερνοται γιατι εχουνε την βαση σαν απλη αποθηκη δεδομενων...

στην μια περιπτωση κανεις σειριακη αναζητηση και στην αλλη σε Βtree
λογικο ειναι οτι (eav) πολυ ποιο αργο απο (inheritance) γιατι N > logN

και οπτικα η ταχυτητα ..
inheritance -> http://slady.net/java/bt/view.php

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

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

Δημοσίευση από Khronos » 30 Μάιος 2011 18:45

Μάλλον θα καταλήξω στο να έχω διαφορετικούς πίνακες για τα μη κοινά attributes των κατηγοριών.

Το έχω κοιτάξει το σχήμα του magento και είναι υπερβολικά περίπλοκο.

Οπότε καλύτερα περισσότερος κώδικας και να ξέρω τι μου γίνεται, παρά να χάνω τη μπάλα σε ένα τεράστιο πίνακα!

Άβαταρ μέλους
cherouvim
Script Master
Δημοσιεύσεις: 3137
Εγγραφή: 13 Ιούλ 2005 22:56
Τοποθεσία: Athens, Greece
Επικοινωνία:

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

Δημοσίευση από cherouvim » 30 Μάιος 2011 19:01

Khronos έγραψε:Μάλλον θα καταλήξω στο να έχω διαφορετικούς πίνακες για τα μη κοινά attributes των κατηγοριών.

...

Οπότε καλύτερα περισσότερος κώδικας και να ξέρω τι μου γίνεται, παρά να χάνω τη μπάλα σε ένα τεράστιο πίνακα!
Δεν είναι τόσο ο περισσότερος model + query κώδικας. To eav λύνει εύκολα τη δυναμική (από το admin panel) δημιουργία και χρήση νέων πεδίων και κατά 99% για αυτό το λόγο χρησιμοποιείται. Αν δεν έχεις τέτοιο use case τότε μην πας σε eav μοντέλο.

pimpogio
Δημοσιεύσεις: 1080
Εγγραφή: 28 Δεκ 2010 14:08

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

Δημοσίευση από pimpogio » 31 Μάιος 2011 04:07

οι σχεσιακες βασεις δεν φτιαχτηκανε παντως για τετοιο μοντελο..

το eav ουσιαστικα ειναι μια χακια για να παρακαμψεις τους περιορισμους του σχεσιακου μοντελου σε σχεσιακη βαση..

Η μελοντικες βασεις δεδομενων και οι ssd δισκοι θα το λυσουνε αυτο το προβλημα

Βεβαια στα ετοιμα cms επειδη ειναι πολυ γενικου χαρακτηρα το εχουνε παραξηλωσει και το χρησιμοποιουνε συνεχεια..

την διαφορα δεν θα την δεις στους λιγους επισκεπτες θα την δεις σε μεγαλη κινηση...

για Ν=10
σχεσιακο log(10)=1
eav = 10

για Ν=10000
σχεσιακο log(10000)=4
eav = 10000

4 πολυ μικροτερο απο 10000

τωρα ποση ειναι η πραγματικη διαφορα δοκιμασε να κανεις benchmark μονος σου στο lan γιατι δεν νομιζω να βρεις καπου συγκεκριμενη απαντηση...

Άβαταρ μέλους
cherouvim
Script Master
Δημοσιεύσεις: 3137
Εγγραφή: 13 Ιούλ 2005 22:56
Τοποθεσία: Athens, Greece
Επικοινωνία:

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

Δημοσίευση από cherouvim » 31 Μάιος 2011 09:09

Ανάλογα τι κάνεις με το eav και με το πως θέλεις να τραβάς την πληροφορία. Οι ssd που λες είναι άσχετο. Δεν λύνουν το πρόβλημα, απλά το κάνουν να εμφανιστεί αργότερα καθώς η βάση μεγαλώνει.

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

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

Δημοσίευση από jpk » 31 Μάιος 2011 14:32

Πάντα «το καλλίτερο» σχετίζεται με το τι θέλεις να κάνεις και ποιος είσαι. Αν απαντάς με την ίδια απάντηση σε όλες τις περιπτώσεις μάλλον κάτι δεν πάει καλά , στο συγκεκριμένο, στην κατασκευή e-shop αν η απάντηση είναι ίδια σε διαφορετικές προδιαγραφές e-shops μάλλον σημαίνει ότι έμαθες ένα μοντέλο και δεν έχεις διάθεση να ξαναασχοληθείς .

Λες Khronos, ότι θέλεις να φτιάξεις αυτή την εφαρμογή για εκπαιδευτικούς λόγους. Για αυτό τον λόγο η άποψή μου είναι ότι είναι σίγουρα πιο παιδευτικό να δημιουργήσεις ένα κεντρικό πίνακα προϊόντων με όλα τα κοινά χαρακτηριστικά και μέσα από την εφαρμογή διαχείρισης να δώσεις την δυνατότητα δημιουργίας τύπων προϊόντων (με ιδιαίτερα χαρακτηριστικά – πεδία ενός πίνακα ανά τύπο). Στην συνέχεια έχεις την δυνατότητα ή να ορίζεις τον τύπο του προϊόντος στην εισαγωγή προϊόντος (δυναμικό αλλά πολύπλοκο στην χρήση) ή στον ορισμό μιας κατηγορίας προϊόντων (που σημαίνει ότι όλα τα προϊόντα της κατηγορίας έχουν τον ίδιο τύπο προϊόντων – περιοριστικό αλλά εύκολο σχετικά για τον διαχειριστή).

Όπως είπα αυτή είναι η άποψή μου ειδικά για εκπαιδευτικούς λόγους (και γιατί θα χρειαστεί σε εξειδικευμένα έργα) , από την άλλη μεριά κατανοώ απόλυτα την προσθήκη των ιδιαίτερων χαρακτηριστικών ενός προϊόντος είτε με ένα πίνακα αντιστοιχίσεων τιμών – ετικέτας – ID προϊόντος είτε μέχρι και μέσα στον ίδιο πίνακα , καθώς συνήθως (από ότι έχω δει μέχρι τώρα) στις περισσότερες εφαρμογές e-shop τα ιδιαίτερα χαρακτηριστικά που ζητά ο πελάτης δεν ξεπερνούν ούτε τα δύο.

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

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

Δημοσίευση από Khronos » 31 Μάιος 2011 14:46

Με τον τρόπο που λες jpk είναι σχεδιασμένο το magento.

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

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

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

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

Δημοσίευση από jpk » 31 Μάιος 2011 16:21

Εγώ ουσιαστικά σου είπα. Με δεδομένο ότι ο διαχειριστής των e-shops δεν είμαι εγώ και ότι όταν αναφέρομαι σε ιδιαίτερα χαρακτηριστικά ενός προϊόντος δεν αναφέρομαι σε εκείνα που είναι μόνο για εμφάνιση (που είναι στην αναλυτική περιγραφή) αλλά επηρεάζουν την ροή της εφαρμογής, συνήθως χρησιμοποιώ έναν πίνακα ο οποίος εμπεριέχει θέσεις για κάποια (λίγα σχετικά 2 ή 3) ζευγάρια ετικέτας – τιμής (π.χ. SPECIAL_LABEL_1 και SPECIAL_VALUE_1 κ.ο.κ.) και η λογική χτίζεται αναλόγως της απαιτήσεις. Αν ο διαχειριστής ήθελε κάτι τόσο απλό (σχετικά) και εγώ στην εφαρμογή διαχείρισης του έδινα οτιδήποτε άλλο, τότε μόνο προβλήματα θα μπορούσα να έχω.

Υπήρξε όμως και μία περίπτωση (και ελπίζω και στο μέλλον γιατί ήταν επικερδής) που χρειάστηκε να φτιάξω κάτι που είναι σχεδόν το Class Table Inheritance (ανεχτείτε τον αγγλικό όρο , μιας και η μετάφραση θα το έκανε αστείο) – με κάποιες όμως διαφοροποιήσεις. Για αυτό που λες (τα validation) κάποια στοιχειώδη ορίζονται μέσα στον πίνακα όταν ο διαχειριστής εισάγει νέο τύπο προϊόντων (φυσικά ο διαχειριστής δεν έχει ιδέα ότι δημιουργεί νέο πίνακα όπως και η εφαρμογή δεν χρειάζεται να αλλάξει). Δεν είμαι σίγουρος ποιος είναι ο καθιερωμένος τρόπος αλλά αυτούς τους πίνακες τύπων προϊόντων τους «δηλώνει» η εφαρμογή σε έναν κεντρικό πίνακα τύπων. Ακόμα και σε αυτή την περίπτωση προσπάθησα όσο το δυνατόν να περιορίσω την πολυπλοκότητα στην εμπειρία χρήσης του διαχειριστή.

Ελπίζω να βοήθησα με την οπτική μου (αν όχι … δεν τρέχει τίποτα λίγος παραπάνω χρόνος χαμένος). Πάντως σε αυτό που έγραψα πριν ότι το «καλλίτερο» έχει να κάνει με το τι κάνεις και το ποιος είσαι, πρέπει σίγουρα να προσθέσω και με το ποιος θα χρησιμοποιήσει την εφαρμογή σου.

Άβαταρ μέλους
korgr
Honorary Member
Δημοσιεύσεις: 5067
Εγγραφή: 07 Οκτ 2008 18:30
Τοποθεσία: Corinth
Επικοινωνία:

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

Δημοσίευση από korgr » 31 Μάιος 2011 16:35

Εγώ έχω καταλήξει στην εξής λογική (που είναι και η αρχή λειτουργίας του Odyssey στην ουσία).

Αν και απλοποιώ εντελώς χάριν του παραδείγματος, αν ξεκινάς με 3 tables στο μυαλό τότε:

Για μη πολυγλωσσικό e-shop θα χρειαστείς 5 tables
Για πολυγλωσσικό θα χρειαστείς 8 tables.

Σε γενικές γραμμές σε περίπτωση πολυγλωσσικού, κάθε ενότητα (όπου ενότητα φαντάσου ΠΡΟΪΟΝΤΑ) αποτελείται από 2 tables, αυτό που αποθηκεύει τα μη πολυγλωσσικά δεδομένα και αυτό που αποθηκεύει τα πολυγλωσσικά...

Τα άλλα δύο tables είναι:
  • Ένα πχ "sections" που αποθηκεύεις τα στοιχεία της ενότητας, πχ id | mysql-table-name | title
    Μια τυπική εγγραφή:
    1234 | products | ΠΡΟΪΟΝΤΑ (μόνο σε μια γλώσσα αρκεί ο τίτλος γιατί είναι μόνο για τον admin)

    Ένα πχ "fields" που αποθηκεύεις τα στοιχεία των πεδίων κάθε ενότητας, πχ id | sectionID | field-mysql-name | field-description | related-table-name | sort

pimpogio
Δημοσιεύσεις: 1080
Εγγραφή: 28 Δεκ 2010 14:08

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

Δημοσίευση από pimpogio » 01 Ιουν 2011 06:14

αυτο που λες δεν μου φαινετε τοσο λογικο...
αποθηκευεις δηλαδη το ονομα του πινακα ? και που χρειαζετε αυτο ?δεν ειναι πλεονασμος ?

γιατι δεν κανεις ας πουμε στο περιπου αυτο..
langs(langID,name...)
sections(sectID,name...) (pleonasmos mias mporeis na pekseis me hardcoded ints)
cats(catID,sectID....) sectID fk sto sections(sectID)
catsL(catID,langID,perlnk...) (catID,langID)-> combined pk / catID fk sto cats(catID) / langID fk sto langs(langID) / unique perlnk
products(pID,catID...) catID fk cats(catID...)
productsL(pID,langID,perlnk...) (pID,langID)-> combined pk / pID fk sto products(pID) / langID fk sto langs(langID) / unique perlnk
-----to productsExtra einai gia extra properties μe relational schema h alios mporeis na kaneis kai eav-----
productsExtra(pExtraID,pID...) pID fk sto products(pID)
productsExtraL(pExtraID,langID...)-> combined pk(pExtraID,langID) / pExtraID fk sto productsExtra(pExtraID) / langID fk sto langs(langID)
k mporeis na prostheteis sections me tous analogous pinakes px blogPosts / blogPostsL

κατι τετοιο νομιζω οτι ειναι απλο και γρηγορο...
εχει κανεις καλυτερη ιδεα για multilanguage ?

Απάντηση

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

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

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