En html tout seul, non.
InsiderZ > Ça, ça renvoie le produit cartésien de tes tables et c’est pas ce que tu veux faire :
Uniquement en HTML, c’est impossible, il te faut forcément un language qui te permette d’écrire et stocker des données, le plus utilisé est PHP avec une base de donnée. Mais il existe de nombreux forums propulsés : les codes sont déjà tout fait, reste juste à l’adapter.
Pfiouh tu lie jamais deux tables ensemble toi :o ! [MEGA SHOCKED!]
Il va te prendre le premier champs qu’il trouve si tu as des champs qui ont le même nom. Pour y remédier, soit tu renommes tes champs lors de la selection ainsi :
Ainsi il te suffira d’appeler après un mysql_fetch_assoc les champs tch1 et tch2. Sinon tu peux utiliser mysql_fetch_rows qui lui index par des nombre, ainsi tu accèderas au premier champs de ta première table avec ton $array[‘1’] etc… (Je te le décommande, car difficilement compréhensible, et tu changes tout si tu modifies la structure de ta base…
Je dirais non. Avec un JOIN on peux joindre deux tables qui n’ont rien à voir dans une seule requête. Ok ça marche pas toujours, mais si tu cherches dans ta table1 quand ch1=‘10’ et dans ta table2 quand ch2!=0, là un JOIN marche très bien 
!
Je prends les tables city et country de la base de données exemple de MySQL (world).
C’est loin d’être le même nombre de lignes, quand-même hein ? 
Edit : en fait, c’est très exactement le produit des nombres de lignes.
DarKChAm > non, je ne lie jamais deux tables ensemble :o
J’suis pas encore pro de la requête SQL, j’avoue
Mandar > oui il y a une relation bien claire, j’ai un champ en commun sur les deux tables, l’une contient toutes les informations identifiant un article, l’autre contient les textes de ce même article
C’est une relation 1:1 ou 1:N ? (en gros, est-ce que pour un même article, il y a plusieurs textes ?)
Pour un article, un texte. Mais je veux éviter les deux requetes car c’est pour faire un while derrière, et j’ai pas envie de jongler entre plusieurs tableaux.
Alors dans ce cas, tu n’as qu’à faire une jointure sur l’id de l’article.
Ce genre de syntaxe me renvoit toujours une erreur moi, je dois forcément faire un GROUP BY pour COUNT. Enfin peut-être pas dans le cas précis que tu viens de donner.
Tu as un énorme boulot d’optimisation SQL alors je dirais !
[:theexcalibur]
Et ?
Je me doutes que j’ai du boulot d’optimisation, justement j’essaye de comprendre comment ça marche dans ce cas précis, et après j’élargirais au reste de mes pages…
Comme j’ai dit je suis loin d’être le Dieu de la requete… et ce que tu me dis là m’aide pas vraiment vois tu… :sarcastic:
On se calme les enfants 
Moi je suis le dieu de la roquette, à Far Cry ! 
Désolé jeanguy, mais je ne m’attendais pas a lire ce genre de moqueries ici… :neutre:
T’inquiètes, une bonne nuit et on oublie tout
C’est ce que je vais faire tiens, un we bien sportif m’attend encore :sleep:
Ce message n’était pas conforme aux règles d’utilisation du nouveau forum :
Bonne nuit ! :hello:
(sur le baratin SQL)
J’ai pas tout suivi, mais oui tu peux concaténer tes tables. Et oui tu le fais mal.
FROM A, B
[…]
Cela s’appelle un produit cartésien, ou CROSS JOIN. C’est une jointure entre deux tables (les jointures sont toujours des produits cartésiens) sans conditions.
Si tu as ces deux tables
A B
1 4
2 5
3 6
Le produit cartésien n’est rien de plus que :
1 4
1 5
1 6
2 4
2 5
2 6
3 4
3 5
3 6
Si tu fais un LEFT JOIN, tu auras l’ensemble des couples de la forme (a in A \ (a, NULL)), etc.
C’est pour cela que la jointure est coûteuse : si tu as N tuples dans A, M dans B, ça te fait N*M tuples au final. Et en terme de coût temps de processus, c’est dans le même ordre d’idées.
Maintenant, ce que tu cherches à faire c’est concaténer, pas faire un produit cartésien. C’est à dire que tu veux l’union de deux tables pour ne pas te faire chier.
Cela se fait heureusement très bien : avec UNION.
Par contre, l’union de deux ensembles, c’est prendre tous les éléments de manière distincte (par défaut, je crois que ça peut se changer dans certains SGBD).
http://dev.mysql.com/doc/refman/5.0/en/union.html
Dans le meilleure des cas :
(SELECT * FROM a) UNION ALL (SELECT * FROM b)
Il s’agit de l’union telle que pas définie dans les opérateurs ensemblistes. ie: l’union avec les doublons.
Ici, a et b doivent être des tables compatibles. N’espère même pas faire l’union d’une table à trois champs (int, int, varchar(45)) avec une table à trois champs (float, datetime, text) ou dont il n’y a pas le même nombre de champs.
Voilà.
Tu verras, quand tu te feras exploser la gueule. D’autant que Jack Carver il a du mal à s’en servir (il bouge comme il est pas permis, mais couché).
Je vois.
Avec l’aide de mandar, j’ai testé cette solution, qui marche actuellement :
Est-ce mieux ou non, est-ce moins coûteux ? Pour l’instant j’étudie la chose, donc les différentes manières de procéder m’intéressent.
Edit : Je lirais les réponses demain. Bonne nuit :hello:
:hello: et preumz!
c’est bOcoup mieux, et c’est même parfait. Mandarounet sais très bien expliquer le SQL :jap:
Vu que les idarticle sont des clefs, ça doit déjà être indexé donc bon niveau perf
Si c’est bien foutu ça peut utiliser un HASH Index, et faire ce que tu aurais pu faire en PHP en deux requêtes.