κατασκευή website με multilanguage

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

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

Απάντηση
Άβαταρ μέλους
Lykos22
Δημοσιεύσεις: 89
Εγγραφή: 29 Μαρ 2011 16:28
Τοποθεσία: UK

κατασκευή website με multilanguage

Δημοσίευση από Lykos22 » 14 Μαρ 2013 17:18

Έχω ένα multilingual site (έχει μόνο αγγλικά και ελληνικά στην ουσία, αν το λεγεται αυτό multilingual :P) το οποίο έχει τα εξής χαρακτητιστικά:

- Σε μία σελίδα (πχ about.php) όλο το περιεχόμενό της (κείμενο) είναι απλά HTML δηλ. δεν προέρχεται από τη βάση δεδομένων. Επομένως γνωρίζω ότι θα έχει στάνταρ ένα h1, 3 p tags, 5-6 li tags κλπ κλπ και δεν θα μεταβάλεται.

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

Η ερώτησή μου είναι η εξής: Ποιός είναι ο ποιό σωστός/λογίκός τρόπος ώστε να έχει το site μου την υποστήριξη των δύο γλωσσών??

Στην πρώτη περίπτωση έκανα κάτι παρόμοιο με αυτό, κάπως έτσι:

Κώδικας: Επιλογή όλων

<html>
<body>
<ul>
<li><a href="index.php"><?php echo $lang&#91;'INDEX'&#93;; ?></a></li>
<li><a href="about.php"><?php echo $lang&#91;'ABOUT'&#93;; ?></a></li>
<li><a href="?lang=eng">English</a></li>
</ul>
<h1><?php echo $lang&#91;'WELCOME'&#93;; ?></h1>
<p><?php echo $lang&#91;'LOREM'&#93;; ?></p>
<p><?php echo $lang&#91;'IPSUM'&#93;; ?></p>
</body>
</html>
Τα links του menu μπορούν εύκολα να μπουν σε ένα $lang array, αλλά για το υπόλοιπο περιεχόμενο της σελίδας είναι ο πιο κατάληλος τρόπος να γίνει αυτό?? Αν υποθέσουμε ότι σε μία παράγραφο το κείμενό της είναι αρκετά μεγάλο?

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

Κώδικας: Επιλογή όλων

&#40;table name&#41;albums&#58;
album_id
name_eng
name_gre
description_eng
description_gre
date_created
...

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

κατασκευή website με multilanguage

Δημοσίευση από korgr » 14 Μαρ 2013 18:52

Χρειάζεσαι δύο πίνακες
Ο ένας αποθηκεύει τα δεδομένα που δεν εξαρτώνται από γλώσσα
πχ id, album_id, date_created κλπ

Ο άλλος αποθηκεύει όλα τα δεδομένα που πρέπει να μεταφράζονται σε διάφορες γλώσσες
πχ article_id (το id του άλλου πίνακα), langID (το id της γλώσσας), title, description, other fields...

Φυσικά θα έχεις και ένα πίνακα με τις γλώσσες:
πχ id 1 -> English, id 2 -> Ελληνικά, κλπ κλπ

Μετά με ένα join και ανάλογα το $langID, τραβάς το περιεχόμενο σε όποια γλώσσα θέλεις...

gi0rg0s
Δημοσιεύσεις: 155
Εγγραφή: 25 Ιούλ 2009 06:13

κατασκευή website με multilanguage

Δημοσίευση από gi0rg0s » 15 Μαρ 2013 02:06

Εγώ συνήθως το έκανα με xml αλλά καλύτερη προσέγγιση αυτή που προτείνεις.
:think: Γιατί μπαμπά; :think: - Απαντήσεις σε θέματα που όλοι έχουμε σκεφτεί παρατηρώντας την καθημερινή ζωή ! Kαι γνωμικά για να μαθαίνουμε :)

Άβαταρ μέλους
Lykos22
Δημοσιεύσεις: 89
Εγγραφή: 29 Μαρ 2011 16:28
Τοποθεσία: UK

κατασκευή website με multilanguage

Δημοσίευση από Lykos22 » 15 Μαρ 2013 09:53

Καταρχήν ευχαριστώ για τις πληροφορίες.

@korgr:
1. οι πίνακές μου δηλαδή θα είναι στην συγκεκριμένη περίπτωση ετσι?:

Κώδικας: Επιλογή όλων

table&#58; albums
album_id &#40;PK&#41;
date_created
visible
---------------------------- 

table&#58; pages*
page_id &#40;PK&#41;
----------------------------

table&#58; languages
lang_id  &#40;PK&#41;
album_id
page_id*
album_title
album_description
page_content
* = θα χρειαστεί να φτιάξω πίνακα pages σε περίπτωση που έχω μόνο περισσότερες από μία σελίδες που μεταβάλλεται το περιεχόμενό τους, σωστά?

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

@gi0rg0s: Άρα συνεχίζω ως έχει στην πρώτη περίπτωση.


Με λίγο ψάξιμο βρήκα και μία προσέγγιση όπου τη γλώσσα τη βάζεις ώς πεδίο στον πίνακα που θες, δηλαδή:

Κώδικας: Επιλογή όλων

table&#58; albums
album_id &#40;PK&#41;
description
folder_name
date_created
visible
language
Είναι λάθος αυτό??

Apostolis_38
Δημοσιεύσεις: 1969
Εγγραφή: 14 Φεβ 2008 16:20
Τοποθεσία: ΠΕΙΡΑΙΑΣ

κατασκευή website με multilanguage

Δημοσίευση από Apostolis_38 » 15 Μαρ 2013 10:47

Θεωρητικά ναι γιατί κάθε μια γλώσσα τα

Κώδικας: Επιλογή όλων

description
folder_name
date_created
visible 
θα πρέπει να επαναλαμβάνονται.
Κάτι που στην πράξη πιθανώς να μην είναι και τόσο άσχημο, αλλά βασικά εξαρτάται από τον όγκο των δεδομένων.

Εγώ πάντως χρησιμοποιώ την πρώτη σου σκέψη που είναι και η απλούστερη, πιο γρήγορη, καταπονεί λιγότερο τον server και δεν χρειάζεται μισό χιλιόμετρο queries.

Κώδικας: Επιλογή όλων

album_id
name_eng
name_gre
description_eng
description_gre
date_created 
Το πολύ πολύ αν θές να αλλάξεις κάτι στον πίνακα είναι μια εντολή (add ή drop) υπόθεση.

Και στο select κάνεις κάτι σαν κι αυτό

Κώδικας: Επιλογή όλων

$lang = $_GET&#91;'lang'&#93;;

SELECT name_'.$lang.' FROM πίνακας κ.λ.π. κ.λ.π.
και εμφανιζεις ότι θέλεις ανάλογα την γλώσσα του χρήστη.

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

κατασκευή website με multilanguage

Δημοσίευση από korgr » 15 Μαρ 2013 11:52

Αποστόλη έχεις διαβάζει περί normalization?
Κάποτε και σε μένα φάνταζε η προσέγγιση σου η πιο εύκολη και σωστή.
Multilingual data με ένα πίνακα, απλά είναι λάθος και θα βγει σε βάθος χρόνου.
Πρέπει να δοκιμάσεις να στήσεις ένα δικό σου CMS για να καταλάβεις πόσο λάθος είναι ο ένας πίνακας!

Η μέθοδος σου είναι εξαρτώμενη από τον αριθμό γλωσσών (αλλά και από το ποιες είναι η γλώσσες κάθε φορά).
Αυτό που έδωσα ισχύει από μία έως άπειρες γλώσσες :)

Lykos22, όχι δεν έχεις καταλάβει την θεωρία. Είδα πως επισκέφθηκες και άλλο θέμα που το αναλύσαμε σε πολλές σελίδες παλαιότερα. Καλύτερα μελέτησε εκεί.

Ένα αναλυτικό παράδειγμα που δημοσίευσα σε άλλο θέμα:

Δημιούργησε

1. ένα πίνακα `languages` πχ
id, language_title
--------------------
1, 'Ελληνικά'
2, 'Αγγλικά'
3, 'Γερμανικά'
2. ένα πίνακα `items` που θα αποθηκεύεις τα μη πολυγλωσσικά δεδομένα

3. ένα πίνακα `translations_items` που θα αποθηκεύεις τα πολυγλωσσικά δεδομένα

Μετά στον πίνακα `translations_items` που έχεις τις μεταφράσεις σε όλες τις γλώσσες, η εγγραφή για ένα αντικείμενο (πχ για το αντικείμενο με id=45) θα είναι κάπως έτσι:
id, title, description, langID, itemID
-----------------------------------------------------
145, 'ελληνικός τίτλος', 'ελληνική περιγραφή', 1, 45
146, 'αγγλικός τίτλος', 'αγγλική περιγραφή', 2, 45
147, 'γερμανικός τίτλος', 'γερμανική περιγραφή', 3, 45
και το query κάπως έτσι για να πάρεις τα αγγλικά του αντικειμένου με id 45:

κώδικας:

Κώδικας: Επιλογή όλων

$langID = &#40;int&#41;$_GET&#91;'langID'&#93;; // η επιλεγμένη γλώσσα... 
$itemID = &#40;int&#41;$_GET&#91;'itemID'&#93;; // ας υποθέσουμε πως είναι 45... 

$q = "select * from `items`, `translations_items` 
where items.id='$itemID' and 
items.id=translations_items.itemID and 
translations_items.langID='$langID'"; 

$result = mysql_query&#40;$q&#41; or die&#40;mysql_error&#40;&#41;&#41;;

Apostolis_38
Δημοσιεύσεις: 1969
Εγγραφή: 14 Φεβ 2008 16:20
Τοποθεσία: ΠΕΙΡΑΙΑΣ

κατασκευή website με multilanguage

Δημοσίευση από Apostolis_38 » 15 Μαρ 2013 12:06

Ναι, έχω διαβάσει.
Στη συγκεκριμένη περίπτωση όμως νομίζω πως δεν αξίζει να θυσιάσεις ότι κερδίζεις για χάρη της "σωστής" τυποποίησης.
ΙΟταν το πράγμα αρχίσει να ξεφεύγει (πάνω από 5-6 γλώσσες) είναι καλύτερη η προσέγγιση που χρησιμοποιείς.
Για ένα πλήθοςόμως 2-3-4 γλωσσών πιστεύω πως είναι περιττό.

Και εξάλλου ένα CMS έχει εκ προοιμίου διαφορετική και πιο αναλυτική υλοποίηση.
Εδώ δεν είναι CMS και πολλές λειτουργίες-θεωρίες τους δεν υφίστανται καν.

Άβαταρ μέλους
Lykos22
Δημοσιεύσεις: 89
Εγγραφή: 29 Μαρ 2011 16:28
Τοποθεσία: UK

κατασκευή website με multilanguage

Δημοσίευση από Lykos22 » 15 Μαρ 2013 12:40

Στην δική μου περίπτωση η γλώσσες που θέλω να χρησιμοποιήσω είναι ελληνικά και αγγλικά μόνο. Τώρα, το site δεν είναι ακριβώς cms, με την ευρύτερη έννοια που όλοι το ξέρουμε (τύπου Joomla, Wordpress ). Πάντως δεν είναι ότι βρίσκω την προσέγγιση του korgr λάθος.

εδώ λέει:
cn92 ανέφερε:
Η καλύτερη λύση νομίζω είναι να δημιουργείται ένας νέος πίνακας για κάθε γλώσσα

Και εγώ πάντως αυτή την λύση χρησιμοποιώ συνήθως όταν έχω να κάνω με πολύγλωσσες εφαρμογές (εκτός από τα βασικά που μπαίνουν στα properties κάθε domain ή subdomain που αντιστοιχεί σε κάθε γλώσσα).

Αυτό βέβαια σημαίνει ότι έχεις ένα τελείως διαφορετικό σύνολο ανά γλώσσα.

Αν θέλεις το σύνολο να είναι το ίδιο και π.χ. πατώντας ένα εικονίδιο αλλαγής γλώσσας σε ένα άρθρο να πηγαίνει στην αντίστοιχη μετάφραση του συγκεκριμένου άρθρου &#8211; σελίδας τότε αναγκαστικά πηγαίνεις στην λύση που προαναφέρθηκε ή σε κάποια παρεμφερή.
Επίσης:
cherouvim ανέφερε:
Σκέψου το εξής:

κώδικας:
table articles: id, created_at, created_by, category_id, state, ...

table article_translations: article_id, language, title, description, ...


αυτο ειναι η σωστη απαντηση στη γενικη περιπτωση και το καλυτερο overall

το εξτρα πεδιο ειναι ποιο ευκολο στην υλοποιηση ειναι ποιο γρηγορο αλλα εχεις fixed
αριθμο σε γλωσσες
το αλλο με εξτρα πινακα σε καθε γλωσσα ειναι λαθος.
μήπως σε αυτή την περίπτωση είναι καλύτερο αυτό που έχω ήδη και ανέφερε ο Apostolis_38 στο προηγούμενο post του??? :-?

Επίσης στην περίπτωση που κάνεις INSERT & UPDATE εκτελείς μία φορά ένα query, στην περίπτωση του korgr και όπως αναφέρεται εδώ γίνονται 2 Inserts ( επί ευκαιρία αυτό με το transaction δεν κατάλαβα τι μπορεί να είναι. έψαξα λίγο στο google αλλά δεν μπορώ να πω ότι βρήκα κάποιο παράδειγμα).

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

κατασκευή website με multilanguage

Δημοσίευση από Khronos » 15 Μαρ 2013 13:12

Apostolis_38 έγραψε:Για ένα πλήθοςόμως 2-3-4 γλωσσών πιστεύω πως είναι περιττό
Και αν μετά απο 1-2-3 χρόνια σου ζητήσει ο πελάτης κ την πέμπτη γλώσσα, τι θα κάνεις?
Θα ψάχνεις βάσεις και θα αλλάζεις κώδικα? Αυτό είναι το όλο θέμα, εκτός το normalization.
Εκτός αν επιδιώκεις να έχεις τέτοια δουλειά! :P

Apostolis_38
Δημοσιεύσεις: 1969
Εγγραφή: 14 Φεβ 2008 16:20
Τοποθεσία: ΠΕΙΡΑΙΑΣ

κατασκευή website με multilanguage

Δημοσίευση από Apostolis_38 » 15 Μαρ 2013 13:38

Εξυπακούεται οτι θα πληρώσει κάτι παραπάνω. :D
Και τότε απλώς ανεβάζεις ένα scriptάκι ή ανοίγεις το phpmyadmin και προσθέτεις ένα πεδίο.
Σε άλλη εφαρμογή το έχω δώσει και σαν όψιον στο διαχειριστικό κομμάτι. Δεν είναι κάτι τραγικό.

Αυτό είναι κάτι τελείως διαφορετικό από την CMS προσέγγιση όπου κυριαρχεί το "διαίρει και βασίλευε".
Εδώ έχουμε έναν πίνακα, σπανίως και δεύτερο, και το θεωρώ περιττό να "παγιδεύεσαι" στα standards (normilization κ.λ.π.) αφού δεν προσφέρουν κάτι περισσότερο.

Και όσον αφορά τον κώδικα δεν αλλάζεις και πολλά πράγματα.
Μόνο ένα έξτρα a href=file.php?lang=new_lang βάζεις.

gvre
Δημοσιεύσεις: 992
Εγγραφή: 14 Οκτ 2010 11:34
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από gvre » 15 Μαρ 2013 15:18

@Lykos22 Κάνε το όπως σου έγραψε ο korgr και ξεμπερδεύεις. Τα queries τα γράφεις μια φορά. Δεν έχει σημασία αν είναι 1 ή 3 γραμμές. Αυτά με τα name_eng, name_gre καλό είναι να τα αποφύγεις. Θα έχει πλάκα κάποια στιγμή να έχεις αυτά τα πεδία και γλώσσες πχ ιταλικά και γερμανικά :)
Και μην το δέσεις κόμπο ότι το site θα είναι σίγουρα μόνο σε αυτές τις γλώσσες. Δεν ξέρεις τι ανάγκη μπορεί να προκύψει.

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από burnmind » 15 Μαρ 2013 18:15

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

Προσοχή, το test ΔΕΝ επιχειρεί να δώσει κάποια απάντηση στο ποια μέθοδος είναι καλύτερη, καθώς αυτό είναι συνάρτηση πάρα πολλών δεδομένων και καταστάσεων που δε γίνεται να αποτυπωθούν σε ένα απλό (και κατασκευασμένο στα γρήγορα) test όπως το παρακάτω.

Case 1:
Έχουμε έναν και μοναδικό πίνακα, τον items, με το εξής structure:

Κώδικας: Επιλογή όλων

CREATE TABLE IF NOT EXISTS `items` &#40;
  `id` int&#40;10&#41; NOT NULL AUTO_INCREMENT,
  `cat_id` int&#40;3&#41; NOT NULL,
  `name_en` varchar&#40;1000&#41; DEFAULT NULL,
  `name_gr` varchar&#40;1000&#41; DEFAULT NULL,
  `desc_en` text,
  `desc_gr` text,
  `published` tinyint&#40;1&#41; NOT NULL,
  `photo` varchar&#40;300&#41; NOT NULL,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00&#58;00&#58;00',
  PRIMARY KEY &#40;`id`&#41;
&#41; ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=100001 ;
Περιέχει 100.000 records, του στυλ:

Κώδικας: Επιλογή όλων

50000, 10, 'This is a sample title', NULL, '5 παράγραφοι του Lorem ipsum', NULL, 1, 'sample_photo_filename.jpg', 2013-03-15 12&#58;07&#58;12, 2013-03-15 12&#58;07&#58;12
Case 2:
Έχουμε 3 πίνακες:

Τον Items, που έχει το εξής structure:

Κώδικας: Επιλογή όλων

CREATE TABLE IF NOT EXISTS `items` &#40;
  `id` int&#40;10&#41; NOT NULL AUTO_INCREMENT,
  `cat_id` int&#40;3&#41; NOT NULL,
  `published` tinyint&#40;1&#41; NOT NULL,
  `photo` varchar&#40;300&#41; NOT NULL,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00&#58;00&#58;00',
  PRIMARY KEY &#40;`id`&#41;
&#41; ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=50001 ;
και περιέχει 50.000 records (υποτίθεται πως είναι το περιεχόμενο που δεν αλλάξει κατά τη μετάφραση) του στυλ:

Κώδικας: Επιλογή όλων

1, 10, 1, 'sample_photo_filename.jpg', 2013-03-15 12&#58;07&#58;12, 2013-03-15 12&#58;07&#58;12
Τον translations_items, που έχει το εξής structure:

Κώδικας: Επιλογή όλων

CREATE TABLE IF NOT EXISTS `translations_items` &#40;
  `id` int&#40;10&#41; NOT NULL AUTO_INCREMENT,
  `name` varchar&#40;1000&#41; NOT NULL,
  `description` text NOT NULL,
  `lang_id` int&#40;3&#41; NOT NULL,
  `item_id` int&#40;10&#41; NOT NULL,
  PRIMARY KEY &#40;`id`&#41;
&#41; ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=100001 ;
και περιέχει 100.000 records (υποτίθεται πως είναι το μεταφρασμένο περιεχόμενο - 2 records για κάθε ένα του items) του στυλ:

Κώδικας: Επιλογή όλων

1, 'This is a sample title', '5 παράγραφοι του Lorem ipsum', 1, 1
Και τον languages, που έχει το εξής structure, και 2 records (gr/en):

Κώδικας: Επιλογή όλων

CREATE TABLE IF NOT EXISTS `languages` &#40;
  `id` int&#40;3&#41; NOT NULL AUTO_INCREMENT,
  `title` varchar&#40;50&#41; NOT NULL,
  PRIMARY KEY &#40;`id`&#41;
&#41; ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;
Case 3:
Έχουμε 2 πίνακες:

Τον Items, που έχει το εξής structure:

Κώδικας: Επιλογή όλων

CREATE TABLE IF NOT EXISTS `items` &#40;
  `id` int&#40;10&#41; NOT NULL AUTO_INCREMENT,
  `cat_id` int&#40;3&#41; NOT NULL,
  `name` varchar&#40;1000&#41; NOT NULL,
  `description` text NOT NULL,
  `lang_id` int&#40;3&#41; NOT NULL,
  `published` tinyint&#40;1&#41; NOT NULL,
  `photo` varchar&#40;300&#41; NOT NULL,
  `updated_at` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `created_at` timestamp NOT NULL DEFAULT '0000-00-00 00&#58;00&#58;00',
  PRIMARY KEY &#40;`id`&#41;
&#41; ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=100001 ;
και περιέχει 100.000 records του στυλ:

Κώδικας: Επιλογή όλων

1, 10, 'This is a sample title', '5 παράγραφοι του Lorem ipsum', 1, 1, 'sample_photo_filename.jpg', 2013-03-15 12&#58;07&#58;12, 2013-03-15 12&#58;07&#58;12
Και τον languages, που έχει το εξής structure, και 2 records (gr/en):

Κώδικας: Επιλογή όλων

CREATE TABLE IF NOT EXISTS `languages` &#40;
  `id` int&#40;3&#41; NOT NULL AUTO_INCREMENT,
  `title` varchar&#40;50&#41; NOT NULL,
  PRIMARY KEY &#40;`id`&#41;
&#41; ENGINE=MyISAM  DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;
Μέγεθος:

Τα μεγέθη της κάθε βάσης (βάσει του phpMyAdmin) είναι τα εξής:

Case 1: 261.1 MB
Case 2: 260.9 MB
Case 3: 261.3 MB

Χρόνος εκτέλεσης queries:

Σε κάθε μία από τις περιπτώσεις, έτρεξα 1 query (το οποίο επιστρέφει ένα item), 1000 x 10 φορές μέσα σε ένα for loop, και έβγαλα τον μέσο όρο του χρόνου εκτελέσεως των 1000 queries, και μετά του ενός.

Για το case 1, έτρεξα το εξής query:

Κώδικας: Επιλογή όλων

SELECT id, cat_id, name_en AS name, desc_en AS description, published, photo, updated_at, created_at
FROM items
WHERE id = 50000
Για τα 1000 queries, χρειάστηκε κατά μέσο όρο 0.22168657779694 seconds, άρα περίπου 0.2217 milliseconds για το κάθε query.

Για το case 2, έτρεξα το εξής query*:

Κώδικας: Επιλογή όλων

SELECT items.*, translations_items.name, translations_items.description
FROM items, translations_items
WHERE items.id = 50000 AND items.id = translations_items.item_id AND translations_items.lang_id=1
* έκανα και μία υλοποίηση με joins, αλλά η διαφορά ήταν ελάχιστη και επέλεξα να κρατήσω ως βάση το παράδειγμα του korgr

Για τα 1000 queries, χρειάστηκε κατά μέσο όρο 161.53037741184 seconds, άρα περίπου 161.5304 milliseconds για το κάθε query.

Για το case 3, έτρεξα το εξής query:

Κώδικας: Επιλογή όλων

SELECT id, cat_id, name, description, published, photo, updated_at, created_at
FROM items
WHERE id = 50000 AND lang_id=1
Για τα 1000 queries, χρειάστηκε κατά μέσο όρο 0.22728054523468 seconds, άρα περίπου 0.2273 milliseconds για το κάθε query.

Τα cases 1 & 3 είναι γρήγορα και σχεδόν ίδια. Το 2ο έχει τρομερά μεγάλη αύξηση, κάτι που είναι λογικό αφού ουσιαστικά συνδέει 2 μεγάλους πίνακες, ενώ τα άλλα δύο όχι.

Υπέρ και κατά

Όσον αφορά το case 1, μπορεί να είναι γρήγορο, αλλά δεν είναι καθόλου ευέλικτο στην περίπτωση που χρειαστεί να προστεθούν/αφαιρεθούν γλώσσες, ή/και fields τα οποία είναι διαφορετικά σε κάθε γλώσσα.

Το case 2, είναι πιο αργό στη συγκεκριμένη περίπτωση για τους γνωστούς λόγους, αλλά είναι ευέλικτο στην περίπτωση που θα χρειαστεί να προστεθούν γλώσσες ή/και fields.

Το case 3, είναι εξίσου γρήγορο με το 1, είναι ευέλικτο λόγω του ότι δεν το ενοχλεί αν προστεθούν γλώσσες ή/και fields, αλλά πάσχει στο ότι υπάρχουν duplicate data τα οποία από θέμα χώρου δε μας ενδιαφέρουν καθώς η διαφορά είναι ελάχιστη, αλλά αν σε οποιοδήποτε update πρέπει να αλλάζουν σε κάθε χώρα, είναι πρόβλημα.

Άρα, καταλήγουμε σ'αυτό που έγραψα στην αρχή (και το γράψαν και άλλοι πριν από 'μένα), πως η επιλογή είναι συνάρτηση πολλών δεδομένων και καταστάσεων.

Αν για παράδειγμα έχουμε ένα απλό CMS που έχει άρθρα ανεξάρτητα μεταξύ τους που απλά είναι σε Χ διαφορετικές γλώσσες, τότε πιστεύω πως η 3η επιλογή είναι μία χαρά. Μπορείς να φιλτράρεις τα άρθρα που θέλεις βάσει της γλώσσας, δε σε ενδιαφέρει ο συσχετισμός μεταξύ των άρθρων (ακόμα και αν σε ενδιαφέρει -ως ένα σημείο- λύνεται), και όλα καλά.

Αν όμως, για παράδειγμα, έχουμε ένα eshop και θέλουμε να έχουμε διαφορετικές μεταφράσεις μόνο σε συγκεκριμένα στοιχεία για το ίδιο αντικείμενο (και αρκετά κοινά), τότε θεωρώ πως η μέθοδος των πολλαπλών tables με joins είναι η καλύτερη, καθώς και είναι ευέλικτη στις προσθήκες, και μας αφήνει να έχουμε κοινά δεδομένα που θα αλλάζουν μία φορά για όλες τις μεταφράσεις, αλλά και μπορούμε πχ να τραβήξουμε ένα προϊόν και να δείξουμε όλες τις πιθανές μεταφράσεις του στον χρήστη με ένα query.

Για την πρώτη περίπτωση, αν και την έχω χρησιμοποιήσει σε προσωπικό project για λόγους γρηγοράδας και ευκολίας, δε μπόρεσα να σκεφτώ κάποιο παράδειγμα που να αναφέρεται σε σοβαρό project και να έχει ουσιαστικά υπέρ σε σχέση με τις υπόλοιπες.
Τελευταία επεξεργασία από το μέλος burnmind την 15 Μαρ 2013 20:03, έχει επεξεργασθεί 1 φορά συνολικά.

Άβαταρ μέλους
Lykos22
Δημοσιεύσεις: 89
Εγγραφή: 29 Μαρ 2011 16:28
Τοποθεσία: UK

κατασκευή website με multilanguage

Δημοσίευση από Lykos22 » 15 Μαρ 2013 18:37

Ουάου!!! :clap::clap::clap:

Εγώ προσωπικά θεωρώ ότι με αυτή την απάντηση το καλύπτεις πλήρως το θέμα. Βλέπεις 3 διαφορετικούς τρόπους που μπορείς να προσεγγίσεις το θέμα, συγκρίνεις, και διαλέγεις αυτόν που θεωρείς κατάλληλο την κάθε φορά. Σωραίοςςςς!!! :D

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

κατασκευή website με multilanguage

Δημοσίευση από korgr » 15 Μαρ 2013 20:00

Κάνε μια διόρθωση στο
Τα cases 1 & 2 είναι γρήγορα και σχεδόν ίδια. Το 2ο έχει τρομερά μεγάλη αύξηση,
που πρέπει να γίνει 1 & 3.

Κατά τα άλλα ωραίος όπως πάντα! :D
Σε ευχαριστούμε για τον χρόνο σου!

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από burnmind » 15 Μαρ 2013 20:09

@Lykos22: Το θέμα δεν καλύπτεται πλήρως με τίποτα, αυτά είναι μόνο κάποια από τα πιθανά cases, μόνο και μόνο για να έχουμε και μερικά "πραγματικά" νούμερα. :wink:

@korgr: Fixed & ευχαριστώ :)

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

Απάντηση

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

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

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