Reprise du message précédent :

 
à part la lisibilité, effectivement.

c'est sûr que c'est plus lisible.
 
mais du coup autant faire un switch(1) non? ou bien ça devient trop dégueu?

Plutôt un array et un foreach.
 

effectivement, j'y pense pas pour si peu de data, mais c'est clairement le plus propre

ceci dit, le break c'est un oubli?

edit: ah non rien

Tu peux pas stocker les nom dans un tableau et utiliser un if + in_array () et si ça match, faire un strtolower et virer l'espace ? Je suis sur mobile mais si t'es patient,  je code ça demain matin

ça existe pas les maps en php?

array?

http://php.net/manual/en/language.types.array.php

ben du coup c'est pas une solution pour la question de TheCreator ?

Je me trompe peut être sur ce que tu comptes faire avec une map, mais a priori c'est la solution que je lui proposais là : http://forum.hardware.fr/hfr/Progr [...] m#t2190405

ah ben oui voilà. Je retourne me coucher

bon lundi !

edit: sauf que pourquoi un foreach?
pseudo code

$logos = array('Forever' => 'forever',
               'Kinna' => 'kinna',
               'Midinette' => 'midinette',
               'Rip Curl' => 'ripcurl');
$logo = null;
if ($nom in $logos) {
 $logo = $logos[$nom];
}

$logos = array('Forever' => 'forever',
               'Kinna' => 'kinna',
               'Midinette' => 'midinette',
               'Rip Curl' => 'ripcurl');
$logo = null;
if ($nom in $logos) {
 $logo = $logos[$nom];
}

Parce-que s'il utilisait strpos au lieu de == tout le monde s'est dit (et faut espérer) qu'il avait besoin d'une recherche par substring et non d'une correspondance exacte

Rien testé,  je suis sur l'application android

si les blogs partagent la même base de données, alors un post est attaché a un blog_id et un auteur_id. À partir de là on peut savoir si une personne est propriétaire de tel ou tel post et également que tel post appartient a tel ou tel blog.

Il me semble que c'est "l'architecture" du fonctionnement du Woprdpress multisite..

Question très con sur SQL/PHP (pas trouvé de topic dédié) :
 
J'ai une table de liaison pour me permettre de lier 2 pages. donc j'ai une colonne page1 et une colonne page2.  
 
Quand je veux afficher pour une page Y ses liaisons, je fais une requête de ce genre :  
 

 
Je suis obligé de faire ça vu que l'ID de la page Y peut être dans la première colonne ou la seconde.  
 
mon souci maintenant c'est de compléter ma requete par un LEFT JOIN pour avoir les informations sur les pages liées.  
 
Sauf que ma requête avec LEFT JOIN, peut soit se baser sur le fait d'aller chercher les infos de la page de la colonne 1 ou celle de la colonne 2, vu que je ne sais pas dans laquelle est mon ID et dans laquelle est celle de la page liée. Donc il faudrait que je puisse dans ma requete SQL (et pas après), mettre une condition pour dire en gros :
 

 
Vous visualisez ma problématique ?  
Je n'ai pas trop compris/trouvé comment en SQL on pouvait mettre ce genre de conditions, si vous pouviez m'éclairer
 
Merkiiii

Tu aurais un schéma de tes tables ? Là je bite que dale à ton problème

 
T'es le seul à les comprendre mes questions  
 
"Conditional join" c'est ça que j'aurais du taper dans google
 
Merki beaucoup !    
Amour sur toi !  
 
 
Edit : Ah oui mais en fait le premier post c'était trop beau pour être vrai, c'était le problème du mec, la solution semble donc être un UNION... Bof j'aurais rêvé que le contenu du premier post puisse marcher

2 LEFT JOIN

Sinon revois les données de ta table d'association pour que les liens dans les 2 sens soient insérés. Ce sera + simple pour la lecture.

C'est pourtant pas compliqué...

SELECT * FROM liaisons 
LEFT JOIN pages ON (liaisons.liaisons_page1 ='ID' AND liaisons_page2=pages.pages_id) OR (liaisons_page2 ='ID' AND liaisons_page1 = pages.pages_id)

Ou alors j'ai pas compris la question?

SELECT * FROM liaisons 
LEFT JOIN pages ON (liaisons.liaisons_page1 ='ID' AND liaisons_page2=pages.pages_id) OR (liaisons_page2 ='ID' AND liaisons_page1 = pages.pages_id)

 
J'ai essayé ta méthode en me disant que ce serait trop bien que ça marche, mais ça marchait pas, ça me ressortait l'ensemble de la table
 
Du coup j'ai utilisé la méthode UNION
 

 
Qui marchent même si je suis pas fan, j'aurais préféré la méthode de Skeye

 
Je viens de tester ça change rien

Normalement pas d'ambiguité, mais ça dépend peut-être du sgbd...

faut que je teste...pas normal cette histoire, ça devrait marcher.

Je viens de relire la question de base. C'est une jointure simple, le left join a rien à foutre là. Ou alors j'ai encore raté un truc

SELECT * 
FROM liaisons 
    JOIN pages ON (liaisons.liaisons_page1 ='ID' AND liaisons_page2=pages.pages_id) OR (liaisons_page2 ='ID' AND liaisons_page1 = pages.pages_id)

SELECT * 
FROM liaisons 
    JOIN pages ON (liaisons.liaisons_page1 ='ID' AND liaisons_page2=pages.pages_id) OR (liaisons_page2 ='ID' AND liaisons_page1 = pages.pages_id)

 
Putain j'ai cette manie de foutre des left join partout au lieu de join    
 
Merci skeye

Bonjour, bonjour,

Je tiens tout d'abord à avouer que je suis une brêle en PHP, donc ne m'en voulez pas trop.

J'ai cette ligne de code qui me pose problème :

Lorsque la condition est remplie (ou pas d'ailleurs), cela n'affiche pas "OK", mais toujours la valeur de "$plxPlugin->lang('L_FORM_BUDGET_CHOICE0')". Je ne comprends pas.

Oui.
Ca affiche sa valeur.

\o/ Merci de m'avoir fait m'attarder sur la fonction lang. J'ai cherché un peu et en utilisant $plxPlugin->GetLang('L_FORM_BUDGET_CHOICE0');, ça fonctionne (pas d'echo !).
 
Encore merci !

J'ai la mauvaise manie d'utiliser toujours des "SELECT *" et donc de ne pas spécifier les colonnes que je veux.  
 
Je voudrais savoir en terme de perf, pour des tables de 10/20 colonnes, à partir de combien de row affichés, on peut sentir une différence entre un Select all et un Select précis ?

Ça dépend de ton "select précis" (si tu sélectionnes tous les champs...), et de la liaison entre application et BDD (socket unix, localhost, réseau local, internet, IPoAC). Ah et probablement de la db, de la table, de l'utilisation ou non d'index (index-only scan[0]), etc...

[0] MSSQL sait même ajouter des colonnes non-indexées à un index, pour pouvoir faire de l'index-only scan avec des colonnes qui font pas partie de l'index.