Supposons le contexte suivant : vous avez une application traduite en plusieurs langues.
Pour chacune des langues, vous avez une ou plusieurs chaines de caractères. Et dans votre application, vous faites, par exemple :

__(‘maChaine’);

Ainsi, la chaine appropriée est affichée en fonction de la langue que vous avez sélectionnée.
Suite à cela, vous avez une base de données qui contient chacune de vos chaines avec la langue et la valeur dans cette même langue.

Lorsque vous appellez la fonction __() avec la valeur de votre choix, vous faites donc un appel à votre base de données qui vous retourne la valeur de la chaine pour la langue en cours.

Le problème, c’est que lorsque vous développez votre application, vous ne pensez pas toujours à ajouter la chaine à chaque fois que vous la placez dans votre code source. Cela serait un tantinet lourd.

La procédure stockée suivante vous permet dont de faire la requête de selection adéquate en fonction de la chaine de caractères et de la langue.
Et si il n’y a aucun élément de retourné, elle en ajoutera un dans la base, avec la chaine vide.

Après, vous n’avez plus qu’à remplir toutes les chaines qui ont été ajoutées lorsque vous surfez dans votre application :)

CREATE PROCEDURE getTrads
@chaine varchar(150),
@langue int
AS
BEGIN
SELECT valeur FROM params_langue
WHERE chaine = @chaine
AND id_langue = @langue
IF (@@Rowcount < 1)
INSERT INTO [params_langue] ([chaine], [valeur], [id_langue]) VALUES (@chaine, '', @langue)
END

Note : cette procédure a été construire pour fonctionner sous SQL Server. Elle n’est pas forcément portable sur tous les SGBDR. Notamment la variable @@Rowcount, qui peut ne pas être disponible partout.

Puis appellez votre procédure stockée :

EXECUTE getTrads
"maChaine", 1

Ou 1 est l’identifiant de votre langue (vous pouvez remplacer cet identifiant par son nom si vous le désirez. Mais je vous le déconseille).

4 Réponses à “SQL : créer un nouvel uplet si la requête ne retourne aucun résultat”

  1. Palleas dit :

    « vous pouvez remplacer cet identifiant par son si vous le désirez »

    Son quoi ? ^^ »

    Sinon merci pour ça, je n’ai pas encore pris le temps de me renseigner sur les procédures stockées, mais niveau perf ça se passe comment ?

  2. Damien dit :

    D’un point de vue perf, c’est forcément plus rapide. Tu ne fait qu’une seule transaction avec le serveur, pas deux :)

  3. Amaury dit :

    Quid de la récupération d’objet après l’appel à une procédure stockée ?

    Typiqument, imaginons que notre procédure stockée fasse une analyse plus ou moins complex afin de faire des select. j’aimerais que mon application Symfony+Doctrine ouisse hydrater les objet correspondant.

    A tu une idée de comment s’y prendre ?

  4. Damien dit :

    Le problème des procédures stockées, c’est que ça change énormément en fonction du SGBDR. C’est plutôt lourd.
    Dans le cas précédent, je n’avais pas le choix. Sinon d’un point de vue organisation du projet, je conseille la non utilisation de celles-ci.

    Sinon, MySQL possède une commande RETURN. C’est peut-être de ce côté la qu’il faut chercher.

Laisser une réponse

 
Fork me on GitHub