---

Hej.

Det er godtnok også Mysql, men jeg tror mit problem ligger i hvordan jeg
interfacer fra php, så derfor skriver jeg her.

Jeg har lavet en lille database:

3 tabeller:
gruppe (36 rækker)
boots (189 rækker)
track (350 rækker)

Der indeholder

gruppe:
gruppe_id bigint primær
gruppe_navn varchar index

boots:
boots_id bigint primær
gruppe_id bigint index
boots_navn varchar index
antal_disc char
varighed int
type char index
tracklist char

track:
track_id bigint primær
boots_id bigint index
track_titel varchar index
varighed int

disse tabeller løber jeg så igennem:
$sql="SELECT * FROM gruppe WHERE gruppe_id";
$res=mysql_query($sql) or die(mysql_error());
while($linie=mysql_fetch_row($res)){
$gruppe_id=$linie[0];
$sql2="SELECT * FROM boots WHERE gruppe_id='$gruppe_id'";
$res2=mysql_query($sql2) or die(mysql_error());

printf($linie[1]);
while($linie2=mysql_fetch_row($res2)){
if($linie2[6]=="y"){
skriv linie med link.
}
else{
skriv linie uden link
}
}
}



Ovenstående er et sammenkog af et script, der virker glimrende på
localhost, men når det er oploadet til webhotellet, tager det nogle gange
temmelig lang tid, før jeg får data i browseren. Prøv eventuelt på
http://mogif.de/trade Efter et par klik går det helt død (Audio og
Complete List). Jeg afslutter ikke scriptet med mysql_close() da jeg har
læst at det ikke er nødvendigt. Er det mig der gør noget helt galt
ydelsesmæssigt?

--
mvh
MiChael Foged

---

On Wed, 22 Sep 2004 11:52:18 +0200, Michael Foged wrote:

> Ovenstående er et sammenkog af et script, der virker glimrende på
> localhost, men når det er oploadet til webhotellet, tager det nogle gange
> temmelig lang tid

Webhotellet har antagelig en sløv MySQL-installation, eller en sløv
forbindelse mellem MySQL og PHP, hvis de ligger på forskellige maskiner.

Bortset fra det, er din fremgangsmåde med talrige SQL-kald og et
"manuelt" join i PHP ikke hensigtsmæssig. Du kan sikkert øge performance
betragteligt ved kun at foretage én forespørgsel, hvor du join'er
"gruppe" og "boots" tabellerne på passende vis - altså joining i
databasen i stedet for i din PHP-kode.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On Tue, 21 Sep 2004 12:02:09 +0200, Troels Arvin wrote:

> Webhotellet har antagelig en sløv MySQL-installation, eller en sløv
> forbindelse mellem MySQL og PHP, hvis de ligger på forskellige maskiner.

Det er nok mere din næste kommentar, da phpmyadmin virker hurtig nok.
0.045 sek for at oprette DB'en fra en sql fil lavet på min egen computer.

> Bortset fra det, er din fremgangsmåde med talrige SQL-kald og et
> "manuelt" join i PHP ikke hensigtsmæssig. Du kan sikkert øge performance
> betragteligt ved kun at foretage én forespørgsel, hvor du join'er
> "gruppe" og "boots" tabellerne på passende vis - altså joining i
> databasen i stedet for i din PHP-kode.

Jeg havde egentligt læst om inner-joins på et af de link du gav mig på
d.e.database men havde ikke lige set muligheden for at bruge dem.

Jeg prøver at leje lidt med det.

--
mvH
MichaEL Foged

---

On Tue, 21 Sep 2004 12:02:09 +0200, Troels Arvin wrote:

Jeg tror jeg har årsagen til mit problem. Jeg uploadede mit script til
et nyt webhotel. De har register_globals on i php.ini . Så får jeg navne
konflikt i mine variabler! (ja jeg ved det, dårlig navngivning)

Jeg forsøgt at lave en .htaccess med følgende indhold:

php_flag register_globals off

men det hjalp ikke:/

--
mvh
Michael Foged

---

On Wed, 22 Sep 2004 13:13:17 +0200, Michael Foged wrote:

> Jeg forsøgt at lave en .htaccess med følgende indhold:
>
> php_flag register_globals off

register_globals er vist en af de PHP-options, som man ikke kan
kontrollere med mindre man er systemadministrator på installationen.

Og ja, register_globals er en pine i enden. Men jeg kan nu ikke lige se,
hvordan det nødvendigvis skal give dig så dårlig performance; grunden
må være ret subtil.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On Tue, 21 Sep 2004 13:23:14 +0200, Troels Arvin wrote:

> On Wed, 22 Sep 2004 13:13:17 +0200, Michael Foged wrote:
>
>> Jeg forsøgt at lave en .htaccess med følgende indhold:
>>
>> php_flag register_globals off
>
> register_globals er vist en af de PHP-options, som man ikke kan
> kontrollere med mindre man er systemadministrator på installationen.

skulle nu kunne lade sig gøre, bare ikke med ini_set()
http://www.phpfreaks.com/phpmanual/page/configuration.html#ini.register-globals


> grunden må være ret subtil.

Det var heller ikke mysql's performance, men en variabel der
pludselig havde en væsentlig anden værdi end forventet. Dette fik
scriptet til at foretage samtlige sql kald _mange_ gange.

--
mvh
mIchael Foged

---

Troels Arvin wrote:

>> php_flag register_globals off
>
> register_globals er vist en af de PHP-options, som man ikke kan
> kontrollere med mindre man er systemadministrator på installationen.

jo, det kan man nu godt, hvis og såfremt options er sat i AllowOverride

Problemt kunne også være at det korrekte er:

php_value register_globals off

> Og ja, register_globals er en pine i enden. Men jeg kan nu ikke lige
> se, hvordan det nødvendigvis skal give dig så dårlig performance;
> grunden må være ret subtil.

enig, med mindre variablen overskrives som han skriver i næste indlæg.

--
Take Care
Kim Emax - master|minds - Vi tænker IT for dig...
http://www.masterminds.dk - http://www.emax.dk

---

---

On Tue, 21 Sep 2004 12:12:53 +0200, Anders K. Madsen wrote:

> Jeg vil lige nævne her at jeg har lidt store performance hits med joins i
> mysql. Når man joiner i sql, så svarer det til at søge i en tabel der
> er (tabel1(antal_rk * antal_kol) * tabel2(antal_rk * antal_kol)) stor.

Et DBMS' fornemste opgave er at være god til håndtering af store
datamængder (under samtidig overholdelse af integritetsregler). Hvis du
oplever, at du i PHP (som er ét af de langsomste programmeringssprog)
får bedre performance, ville jeg _umiddelbart_ hævde, at det er et
alarmsignal om, at der er noget helt galt med dit DBMS, eller med måden,
du benytter DBMSet på. Eller også har du eller din databaseadministrator
måske glemt at bede DBMSet indsamle statistik for tabellerne (hvilket er
meget vigtigt for effektiv forespørgselshåndtering).

Det er ikke rigtigt, at et DBMS nødvendigvis behøver at foretage et
komplet kartesisk produkt af de involverede tabeller for at kunne join'e.
Der er skrevet tonsvis af videnskab (og praktisk kode) med henblik på at
søge at opnå effektive forespørgselsafviklinger, herunder joins.

Hvis du virkelig beder den om samtlige rækker og kolonner fra de
involverede tabeller, sammensmeltet uden vilkår - ja så bliver
resultatsættet uhyre stort. Kæmpe resultatsæt overført i én stor
klump - evt. over en sløv forbindelse - er naturligvis ikke smart. Men
hvor ofte er det lige, at man har brug for det?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On Tue, 21 Sep 2004 12:41:55 +0200, Troels Arvin wrote:

>
> Det er ikke rigtigt, at et DBMS nødvendigvis behøver at foretage et
> komplet kartesisk produkt af de involverede tabeller for at kunne join'e.
> Der er skrevet tonsvis af videnskab (og praktisk kode) med henblik på at
> søge at opnå effektive forespørgselsafviklinger, herunder joins.
>
Fra litteraturen om distribuerede databaser opererer man med begrebet
semi-joins (først project, herefter join), som burde kunne hæve
performance betragteligt.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
You are a very redundant person, that's what kind of person you are.