Archief - MySQL: 2 query's mengen

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

HelloApu

Legacy Member
Hallo,

Ik zou dus eigenlijk 2 query's moeten kunnen mengen voor mijn forumpje. Dat er eerst een categorie komt en dan pas de verschillende threads.
Mijn code is nu :
PHP:
<?PHP 
 require("header1.php");
?>
<?PHP
 include("connect.php");
 include("text.php");
 $i = "0";
 $query1 = mysql_query("SELECT id,naam,beschrijving,onderwerpen,berichten,categorie FROM forum") OR die("mysql foutje op lijn ". __LINE__);
 $query2 = mysql_query("SELECT id,naam,afkorting FROM categorie") OR die("mysql foutje op lijn ".__LINE__);
 $query3 = mysql_query("SELECT id,naam,afkorting FROM categorie LIMIT $i,1")OR die("mysql foutje op lijn ".__LINE__);
 $query4 = mysql_query("SELECT id,naam,beschrijving,onderwerpen,berichten,categorie FROM forum WHERE categorie = $i");
 
 $resultaat3 = mysql_fetch_array($query3);
 $resultaat4 = mysql_fetch_array($query4);

 echo "index.php";
 echo "<table border=\"0\">";

 while( $resultaat2 = mysql_fetch_array($query2) )
 { 
  echo "<tr>";
  echo "<td colspan=\"3\" class=\"categorie\">";
  echo $resultaat3[naam];
  echo "</td>";
  echo "</tr>";
	while( $resultaat1 = mysql_fetch_array($query1) )
	{
	echo "<tr>";
	echo "<td class=\"forum\">";
	echo "<a href=\"vieuwforum.php?for=";
	echo $resultaat4[id];
	echo "\">";
	echo $resultaat4[naam];
	echo "</a>";
	echo "<br \>";
	echo $resultaat4[beschrijving];
	echo "</td>";
	echo "<td class=\"forum\">";
	echo $resultaat4[onderwerpen];
	echo "</td>";
	echo "<td class=\"forum\">";
	echo $resultaat4[berichten];
	echo "</td>";
	echo "</tr>";
	}
  $i++;
 }
?>
<?PHP
 include("footer1.php");
?>

Maar die $resultaat3 doet nix uit. Het blijft hetzelfde herhalen

[Scratch]

Legacy Member
Mja, voor je een vrij groot project of script begint te schrijven kan je best even checken voor "database optimalisering" ...

Ik had zo vroeger ook eens een ideetje.

Als test een soort goudengids achtig scripts schrijven

Maar zonder JOINS had ik wel lekker een dikke 250 query's per pagina ... en die server maar flippen :)

Dus eerst database optimaliseren en dan pas scripten :p

sneax

Legacy Member
kunt ge is eenvoudig en snel uitleggen wat JOIN juist doet? is het correct dat het een oplossing is voor als ge bijvoorbeeld info uit de ene table wilt halen maar ge moet selecteren en sorteren met info uit een andere table?

Dece

Legacy Member
stel dit
Code:
+------------------------------------+
|        table member                         |
+------------------------------------+
| id(tinyint(5) auto-increment,unique   |
| naam (varchar(100))                      |
| functie    (tinyint(2))                      |
+------------------------------------+

+-------------------------------------+
|          table benamingen                   |
+-------------------------------------+
| id (tinyint(2) auto-increment, unique   |
| benaming (varchar(10))                    |
+-------------------------------------+
het voordeel van deze structuur is dat je snel een nieuwe benaming kan toevoegen.

de query zal er ongeveer zo uitzien:
SELECT member.naam, benamingen.benaming FROM member INNER JOIN benamingen ON member.functie = benamingen.id

output zal dan
naam en benaming zijn

DarkBone

Legacy Member
JOINS zijn geoptimaliseerde SQL instructies om informatie uit verschillende tabellen op te halen op basis van een bepaalde onderlinge relatie. Die relatie verloopt meestal via de (vreemde) sleutels. Zoniet, dan zal de performantie van uw queries heel wat minder zijn (enkel van sleutels worden snel doorzoekbare indextabellen bijgehouden, waardoor JOINS op basis van sleutels opzich ook extreem snel zijn). Joinen op basis van 'gewone' velden wordt dus niet aangeraden, je legt dan beter een index op dat veld (waardoor zo'n indextabel wordt bijgehouden). Is enkel nuttig als dat veld ook daadwerkelijk veel gebruikt wordt in joins.

sneax

Legacy Member
heel intressant

mijn db structuur is daar perfect voor gepast maar nu doe ik het de 'omslachtige manier' (dus met héél veel queries)

merci =)

Jinx

Legacy Member
da moete ni perse de sleutels zijn he. ge kunt ook nen index zetten op andere velden die eventueel veel gebruikt worden.

Lashknife

Legacy Member
Dece zei:
SELECT member.naam, benamingen.benaming FROM member INNER JOIN benamingen ON member.functie = benamingen.id
is dat dan niet gewoon hetzelfde als dit? of mis ik een of ander voordeel van "join"

select naam, benamingen from member, benamingen where member.functie = benamingen.id;

EdMeister

Legacy Member
Lashknife zei:
is dat dan niet gewoon hetzelfde als dit? of mis ik een of ander voordeel van "join"

select naam, benamingen from member, benamingen where member.functie = benamingen.id;
Idd net hetzelfde. En volgens mij geeft dit geen enkel voordeel.
't Is mij al meermaals opgevallen dat ze hier op dit forum graag met dergelijke structuren werken.

DarkBone

Legacy Member
Da's gewoon een kwestie van notatie. De 'komma' komt overeen met een INNER JOIN. Zoals ook ni de manual staat aangegeven:

INNER JOIN and , (comma) are semantically equivalent in the absence of a join condition: both will produce a Cartesian product between the specified tables (that is, each and every row in the first table will be joined onto all rows in the second table).
Een reden waarom je de voorkeur aan de geschreven INNER JOIN zou kunnen geven, is omdat alle andere JOINS ook voluit worden geschreven (LEFT JOIN, RIGHT JOIN, ...)
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan