Je me pose plusieurs questions pour la création d'un site multilingue.
1. Chaque client dispose d'un nombre de langue définie. Chaque client est enregister dans une table Mysql et j'ai mis un
champs SET pour choisir les langues attribuées à chaque client.
2. J'ai une table langue qui me permet d'être extensible.
ID_langue | langue
1 | fr
2 | en
etc...
3. J'ai plusieurs table qui on cette strucutures:
ID_event | langue | message_event | date_event
Suite à des conseils, je n'ai pas de clé primaire sur cette table. J'ai quelques soucis pour les mises à jour et les
suppression. Lors de la création d'un nouveau event, je fait autant d'INSERT qu'il y a de langue. La méthode est un peu
bizzare:
$requete = "SELECT MAX(ID_event) FROM evenement";
$affichage = mysql_query($requete);
$ID_event = mysql_result($affichage,0,0);
$ID_event=$ID_event+1;
$LangueClient=array('FR','EN','DE');
foreach ($LangueClient as $langue){
$affichage = mysql_query("INSERT INTO evenement (ID_event,langue) VALUES ('$ID_event','$langue')");
}
4. Puis j'affiche les formulaires correspondant aux différentes langue pour " l'ajout des textes dans les langues
respectives. " puis pour chaque langue je fait:
UPDATE evenement SET message_event='$message_event' WHERE ID_event ='$ID_event' AND langue ='$langue' ";
Je n'ai aucun problème pour le fonctionnement, mais je vous pose la question pour voir d'autre piste à explorer.
Merci de pouvoir m'ouvrir les yeux.
--
Stéphane
La souplesse d'esprit permet de s'adapter dans toutes circonstances.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
john gallet
Bonjour,
Suite à des conseils, je n'ai pas de clé primaire sur cette table.
La théorie des SGBDR impose de mettre une clef sur toutes ses tables. Mais il est clair que sur certaines tables "utilitaires" ou si on dénormalise un peu il *peut* arriver qu'elle ne serve de toutes façons à rien.
Et en l'occurence, c'est faux, tu as bien une clef primaire sur ta table ici !! La clef primaire de ta table actuelle est bien une clef composite constituée de l'identifiant que tu incrémentes manuellement et de la langue (tu n'as la droit d'avoir un événement dans une langue qu'une seule fois).
suppression. Lors de la création d'un nouveau event, je fait autant d'INSERT qu'il y a de langue. $requete = "SELECT MAX(ID_event) FROM evenement"; $ID_event=$ID_event+1;
En fait le seul problème se situe là : si tu as plusieurs personnes différentes qui font un ajout d'événement au même moment, ces événements pourtant différents risquent d'avoir le même identifiant.
Autrement dit tu devrais avoir une autre table appelée par exemple evenement_def qui aurait une vraie clef primaire (quitte à ce que de toutes façons ce soit un autoincrement **SI** tu ne peux pas faire mieux), tu fais un insert dans celle là, tu récupères la valeur par mysql_insert_id($dad) et là c'est logique : la clef primaire de ta table actuelle est bien une clef composite constituée de cette clef étrangère et de la langue.
4. Puis j'affiche les formulaires correspondant aux différentes langue pour " l'ajout des textes dans les langues respectives. " puis pour chaque langue je fait: UPDATE evenement SET message_event='$message_event' WHERE ID_event ='$ID_event' AND langue ='$langue' ";
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert systématique de TOUTES les langues pour faire un upadte derrière. Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne langue au moment où (et si) il est saisit ?
a++ JG
Bonjour,
Suite à des conseils, je n'ai pas de clé primaire sur cette table.
La théorie des SGBDR impose de mettre une clef sur toutes ses tables.
Mais il est clair que sur certaines tables "utilitaires" ou si on
dénormalise un peu il *peut* arriver qu'elle ne serve de toutes façons à
rien.
Et en l'occurence, c'est faux, tu as bien une clef primaire sur ta table
ici !! La clef primaire de ta table actuelle est bien une clef composite
constituée de l'identifiant que tu incrémentes manuellement et de la
langue (tu n'as la droit d'avoir un événement dans une langue qu'une
seule fois).
suppression. Lors de la création d'un nouveau event, je fait autant d'INSERT qu'il y a de langue.
$requete = "SELECT MAX(ID_event) FROM evenement";
$ID_event=$ID_event+1;
En fait le seul problème se situe là : si tu as plusieurs personnes
différentes qui font un ajout d'événement au même moment, ces événements
pourtant différents risquent d'avoir le même identifiant.
Autrement dit tu devrais avoir une autre table appelée par exemple
evenement_def qui aurait une vraie clef primaire (quitte à ce que de
toutes façons ce soit un autoincrement **SI** tu ne peux pas faire
mieux), tu fais un insert dans celle là, tu récupères la valeur par
mysql_insert_id($dad) et là c'est logique : la clef primaire de ta table
actuelle est bien une clef composite constituée de cette clef étrangère
et de la langue.
4. Puis j'affiche les formulaires correspondant aux différentes langue pour " l'ajout des textes dans les langues
respectives. " puis pour chaque langue je fait:
UPDATE evenement SET message_event='$message_event' WHERE ID_event ='$ID_event' AND langue ='$langue' ";
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert
systématique de TOUTES les langues pour faire un upadte derrière.
Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne
langue au moment où (et si) il est saisit ?
Suite à des conseils, je n'ai pas de clé primaire sur cette table.
La théorie des SGBDR impose de mettre une clef sur toutes ses tables. Mais il est clair que sur certaines tables "utilitaires" ou si on dénormalise un peu il *peut* arriver qu'elle ne serve de toutes façons à rien.
Et en l'occurence, c'est faux, tu as bien une clef primaire sur ta table ici !! La clef primaire de ta table actuelle est bien une clef composite constituée de l'identifiant que tu incrémentes manuellement et de la langue (tu n'as la droit d'avoir un événement dans une langue qu'une seule fois).
suppression. Lors de la création d'un nouveau event, je fait autant d'INSERT qu'il y a de langue. $requete = "SELECT MAX(ID_event) FROM evenement"; $ID_event=$ID_event+1;
En fait le seul problème se situe là : si tu as plusieurs personnes différentes qui font un ajout d'événement au même moment, ces événements pourtant différents risquent d'avoir le même identifiant.
Autrement dit tu devrais avoir une autre table appelée par exemple evenement_def qui aurait une vraie clef primaire (quitte à ce que de toutes façons ce soit un autoincrement **SI** tu ne peux pas faire mieux), tu fais un insert dans celle là, tu récupères la valeur par mysql_insert_id($dad) et là c'est logique : la clef primaire de ta table actuelle est bien une clef composite constituée de cette clef étrangère et de la langue.
4. Puis j'affiche les formulaires correspondant aux différentes langue pour " l'ajout des textes dans les langues respectives. " puis pour chaque langue je fait: UPDATE evenement SET message_event='$message_event' WHERE ID_event ='$ID_event' AND langue ='$langue' ";
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert systématique de TOUTES les langues pour faire un upadte derrière. Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne langue au moment où (et si) il est saisit ?
a++ JG
Stephane
"john gallet" a écrit,
Autrement dit tu devrais avoir une autre table appelée par exemple evenement_def qui aurait une vraie clef primaire (quitte à ce que de toutes façons ce soit un autoincrement **SI** tu ne peux pas faire mieux), tu fais un insert dans celle là, tu récupères la valeur par mysql_insert_id($dad) et là c'est logique : la clef primaire de ta table actuelle est bien une clef composite constituée de cette clef étrangère et de la langue.
Merci John, J'ai opté pour cette façon de faire, j'ai un table avec un n° autoincrement, puis je le récupère comme tu le mentionnes.
4. Puis j'affiche les formulaires correspondant aux différentes langue pour " l'ajout des textes dans les langues respectives. " puis pour chaque langue je fait: UPDATE evenement SET message_event='$message_event' WHERE ID_event ='$ID_event' AND langue ='$langue' ";
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert systématique de TOUTES les langues pour faire un upadte derrière. Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne langue au moment où (et si) il est saisit ?
Il y a plusieurs champs à remplir. Si il y a 5 langues, ça prend du temps et comme les connexions sur Internet sont pas toujours au top, (Expérience personnel, j'ai passé 15 minutes à remplir un formulaire, puis au submit, connexion down) alors je préfère y aller en plusieurs étapes bien distinctes comme ça je minimise le risque inhérent à Internet.
-- Stéphane La souplesse d'esprit permet de s'adapter dans toutes circonstances.
http://www.velo-passion.com pour les fans de vélo
"john gallet" a écrit,
Autrement dit tu devrais avoir une autre table appelée par exemple
evenement_def qui aurait une vraie clef primaire (quitte à ce que de
toutes façons ce soit un autoincrement **SI** tu ne peux pas faire
mieux), tu fais un insert dans celle là, tu récupères la valeur par
mysql_insert_id($dad) et là c'est logique : la clef primaire de ta table
actuelle est bien une clef composite constituée de cette clef étrangère
et de la langue.
Merci John,
J'ai opté pour cette façon de faire, j'ai un table avec un n° autoincrement, puis je le récupère comme tu le mentionnes.
4. Puis j'affiche les formulaires correspondant aux différentes langue pour " l'ajout des textes dans les langues
respectives. " puis pour chaque langue je fait:
UPDATE evenement SET message_event='$message_event' WHERE ID_event ='$ID_event' AND langue ='$langue' ";
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert
systématique de TOUTES les langues pour faire un upadte derrière.
Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne
langue au moment où (et si) il est saisit ?
Il y a plusieurs champs à remplir. Si il y a 5 langues, ça prend du temps et comme les connexions sur Internet sont pas
toujours au top, (Expérience personnel, j'ai passé 15 minutes à remplir un formulaire, puis au submit, connexion down)
alors je préfère y aller en plusieurs étapes bien distinctes comme ça je minimise le risque inhérent à Internet.
--
Stéphane
La souplesse d'esprit permet de s'adapter dans toutes circonstances.
Autrement dit tu devrais avoir une autre table appelée par exemple evenement_def qui aurait une vraie clef primaire (quitte à ce que de toutes façons ce soit un autoincrement **SI** tu ne peux pas faire mieux), tu fais un insert dans celle là, tu récupères la valeur par mysql_insert_id($dad) et là c'est logique : la clef primaire de ta table actuelle est bien une clef composite constituée de cette clef étrangère et de la langue.
Merci John, J'ai opté pour cette façon de faire, j'ai un table avec un n° autoincrement, puis je le récupère comme tu le mentionnes.
4. Puis j'affiche les formulaires correspondant aux différentes langue pour " l'ajout des textes dans les langues respectives. " puis pour chaque langue je fait: UPDATE evenement SET message_event='$message_event' WHERE ID_event ='$ID_event' AND langue ='$langue' ";
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert systématique de TOUTES les langues pour faire un upadte derrière. Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne langue au moment où (et si) il est saisit ?
Il y a plusieurs champs à remplir. Si il y a 5 langues, ça prend du temps et comme les connexions sur Internet sont pas toujours au top, (Expérience personnel, j'ai passé 15 minutes à remplir un formulaire, puis au submit, connexion down) alors je préfère y aller en plusieurs étapes bien distinctes comme ça je minimise le risque inhérent à Internet.
-- Stéphane La souplesse d'esprit permet de s'adapter dans toutes circonstances.
http://www.velo-passion.com pour les fans de vélo
john gallet
Re,
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert systématique de TOUTES les langues pour faire un upadte derrière. Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne langue au moment où (et si) il est saisit ?
Il y a plusieurs champs à remplir. Si il y a 5 langues, ça prend du temps et comme les connexions sur Internet sont pas toujours au top, (Expérience personnel, j'ai passé 15 minutes à remplir un formulaire, puis au submit, connexion down) alors je préfère y aller en plusieurs étapes bien distinctes comme ça je minimise le risque inhérent à Internet.
Et quelle pourrait bien être la différence de temps passé pour faire un INSERT par rapport à faire un UPDATE ? La mise à jour de l'index placé automatiquement par la commande PRIMARY KEY composite :-) ? Je n'ai pas dit de saisir les N traductions sur une seule page, mais de faire l'insert au moment où on en a besoin.
Bref, tu n'es en rien obligé de mettre 10 rangs pour 10 langues si finalement seulement 2 sont traduits. Si dans tous les cas toutes les langues doivent systématiquement être renseignées, alors ça revient au même donc tu oublies mes chipotages.
a++ JG
Re,
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert
systématique de TOUTES les langues pour faire un upadte derrière.
Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne
langue au moment où (et si) il est saisit ?
Il y a plusieurs champs à remplir. Si il y a 5 langues, ça prend du temps
et comme les connexions sur Internet sont pas
toujours au top, (Expérience personnel, j'ai passé 15 minutes à remplir
un formulaire, puis au submit, connexion down)
alors je préfère y aller en plusieurs étapes bien distinctes comme
ça je minimise le risque inhérent à Internet.
Et quelle pourrait bien être la différence de temps passé pour faire un
INSERT par rapport à faire un UPDATE ? La mise à jour de l'index placé
automatiquement par la commande PRIMARY KEY composite :-) ?
Je n'ai pas dit de saisir les N traductions sur une seule page, mais de
faire l'insert au moment où on en a besoin.
Bref, tu n'es en rien obligé de mettre 10 rangs pour 10 langues si
finalement seulement 2 sont traduits.
Si dans tous les cas toutes les langues doivent systématiquement être
renseignées, alors ça revient au même donc tu oublies mes chipotages.
Là j'avoue que je ne vois pas bien l'intérêt de faire cet insert systématique de TOUTES les langues pour faire un upadte derrière. Pourquoi ne pas simplement faire l'insert avec le texte dans la bonne langue au moment où (et si) il est saisit ?
Il y a plusieurs champs à remplir. Si il y a 5 langues, ça prend du temps et comme les connexions sur Internet sont pas toujours au top, (Expérience personnel, j'ai passé 15 minutes à remplir un formulaire, puis au submit, connexion down) alors je préfère y aller en plusieurs étapes bien distinctes comme ça je minimise le risque inhérent à Internet.
Et quelle pourrait bien être la différence de temps passé pour faire un INSERT par rapport à faire un UPDATE ? La mise à jour de l'index placé automatiquement par la commande PRIMARY KEY composite :-) ? Je n'ai pas dit de saisir les N traductions sur une seule page, mais de faire l'insert au moment où on en a besoin.
Bref, tu n'es en rien obligé de mettre 10 rangs pour 10 langues si finalement seulement 2 sont traduits. Si dans tous les cas toutes les langues doivent systématiquement être renseignées, alors ça revient au même donc tu oublies mes chipotages.
