[PHP] Select quey zeer langzaam

[mathijs92]

Ik heb in PHP een script gemaakt dat data uit een text-veld in een MySQL database moet halen, in PHPMyAdmin wordt die data meteen geopend, maar mijn script wil er meer dan 300 seconden over doen, terwijl de data eigenlijk niet zo groot is, en het maar 1 rij is. De PHP foutmelding geeft aan dat de max_execution_time van 300 secondes wordt overschreden op lijn 82

PHP:

$sql = "SELECT * FROM `tb_orders` WHERE sessie='$sid' AND adreskode='$adreskode' ";
$res = mysql_query($sql);
$num = mysql_num_rows($res);
if($num==0){
echo "Er zijn geen artikelen toegevoegd";
}else{
while($row = mysql_fetch_array){
$order = $row['artikeldrager'];
}
$order = unserialize($order);
$artikelen = array_keys($order);
$count = count($artikelen);
echo $num;
for($i=0; $i<$count; $i++){
$artikel = $artikelen[$i];
echo $artikel;

}
}

het veld artikeldrager is het grootste veld, daar staat dit in

a:23:{s:14:"artikel3";a:4:{i:0;i:2008022792;i:1;i:2008022802;i:2;i:2008023116;i:3;i:2008023151;}s:14:"artikel2";a:3:{i:0;i:2008019943;i:1;i:2008019945;i:2;i:2008019942;}s:14:"artikel5";a:3:{i:0;i:2008023156;i:1;i:2008023157;i:2;i:2008019940;}i:0;s:5:"order";i:1;s:5:"order";i:2;s:5:"order";i:3;s:5:"order";i:4;s:5:"order";i:5;s:5:"order";i:6;s:5:"order";i:7;s:5:"order";i:8;s:5:"order";i:9;s:5:"order";i:10;s:5:"order";i:11;s:5:"order";i:12;s:5:"order";i:13;s:5:"order";i:14;s:5:"order";i:15;s:5:"order";i:16;s:5:"order";s:14:"artikel1"a:4:{i:0;i:2008023166;i:1;i:2008023172;i:2;i:2008023176;i:3;i:2008019955;}i:17;s:5:"order";i:18;s:5:"order";}

Zoals ik al zei, in PHPMyAdmin wordt dit eigenlijk meteen geladen, er is dus iets mis in mijn script, alleen heb ik helemaal geen idee waar het aan ligt.

[vorlox]

moet er geen result naar mysql_fetch_array?

[oef]
en verder je artikelen als serialized array in een DB stoppen is volgens mij niet the way to go
[/oef]

[SQL] En waarom normaliseer jij niet?

[ Voor 20% gewijzigd door vorlox op 15-07-2008 10:31 ]

[Xander]

Hoeveel results geeft die query?

Bij meer dan 1 result is je script in ieder geval niet echt logisch, $order wordt in die whilelooop steeds overschreven.

[ Voor 24% gewijzigd door Xander op 15-07-2008 10:26 ]

[Morax]

Ik zou je resultset meegeven als argument aan mysql_fetch_array()

[Niemand_Anders]

Volgens mij moet je eerst ook een connectie met je database openen (mysql_(p)connect) voordat je een query kunt uitvoeren. mysql_query (volgens PHP handleiding) gebruikt zonder de resource identifier de laatst geopende connectie. Maar ik zie in jouw code geen mysql_connect() en geen mysql_close() terug komen.

Probeer eens de volgende query uit te voeren ' select 1 + 1 as Anwser '.

[mathijs92]

mysql_connect staat in config.php, was dus vergeten op de resultset mee te geven nu werkt het wel, nog steeds iets langzamer dan phpmyadmin, maar niet veel meer

[Megamind]

Zowiezo maak je nog geen verbinding met je DB...

Zet je error_reporting eens op E_ALL, en je zal ook zien dat mysql_fetch_array een array teruggeeft, en niet benaderd kan worden met $order = $row['artikeldrager'];

[vorlox]

mathijs92 schreef op dinsdag 15 juli 2008 @ 10:28:
mysql_connect staat in config.php, was dus vergeten op de resultset mee te geven nu werkt het wel, nog steeds iets langzamer dan phpmyadmin, maar niet veel meer

mysql_connect staat in config.php

?? config.php

[mathijs92]

je ziet dat de code pas bij regel 75 begint, daarboven staat stijl + tabellen enzo, maar dus ook include("config.php");

[LuCarD]

PHP:

while($row = mysql_fetch_array){
$order = $row['artikeldrager'];
}

dit is een end-less loop

Je mist namelijk de () na mysql_fetch_array. Waarom doe je trouwens een loop als je maar 1 record terug wilt hebben?

[MueR]

Je gebruikt 1 veld in je code, waarom selecteer je dan de hele rij? SELECT * FROM is zo'n brakke constructie...

[Zyppora]

LuCarD schreef op dinsdag 15 juli 2008 @ 10:44:

PHP:

while($row = mysql_fetch_array){
$order = $row['artikeldrager'];
}

dit is een end-less loop

Je mist namelijk de () na mysql_fetch_array. Waarom doe je trouwens een loop als je maar 1 record terug wilt hebben?

Hij wil niet 1 record terughebben, maar meerdere. Hij stopt die meerdere alleen in een serialized array in zijn database De loop is goed, de uitvoering echter niet. 5 regels verderop wordt er namelijk overnieuw geloopt.

Wat vorlox zegt dus: normaliseren.

vorlox schreef op dinsdag 15 juli 2008 @ 10:32:
[...]


mysql_connect staat in config.php

?? config.php

Overigens kan ik me best voorstellen dat men de connectie naar een database wil openen in een apart script dat overal wordt ge-include. Dat dat script 'config.php' heet, doet niets af aan het concept. Ik ben het met je eens dat het niet de perfecte oplossing is, magoed, we zijn niet allemaal PHP gurus

[Voutloos]

Select *, geen limit, geen escaping, rare loop met uitlezen, diverse PHP notices, wellicht (aanname) geen indexen, geen indenting, etc. etc.

En als je Engelse en Nederlandse var namen door elkaar heen gebruikt -wat sowieso zuigt- is $order nogal ambigue.

[ Voor 35% gewijzigd door Voutloos op 15-07-2008 11:26 ]

[Niekk]

En doe jezelf een plezier, en leer in te springen in je code

[curry684]

mathijs92 schreef op dinsdag 15 juli 2008 @ 10:28:
mysql_connect staat in config.php, was dus vergeten op de resultset mee te geven nu werkt het wel, nog steeds iets langzamer dan phpmyadmin, maar niet veel meer

Als jij gaat verhuizen schrijf je ook 'keukenspullen' op een doos met CD's? Oftewel: waarom ga je in godesnaam business logic uitvoeren in een bestand dat volgens de naam zuiver configuratie bevat?

LuCarD schreef op dinsdag 15 juli 2008 @ 10:44:

PHP:

while($row = mysql_fetch_array){
$order = $row['artikeldrager'];
}

dit is een end-less loop

Je mist namelijk de () na mysql_fetch_array. Waarom doe je trouwens een loop als je maar 1 record terug wilt hebben?

Die code geeft ook een paar dikke warnings, dus iemand moet hier nog even wat aan z'n error reporting instellingen doen

[BastiaanN]

Je moet aan mysql_fetch_array toch altijd de resource meegegeven waarvan wat opgehaald moet worden? dus...

PHP:

while($row = mysql_fetch_array($res)){ 
$order = $row['artikeldrager']; 
}

Edit; idd, net wakker sorry!

[ Voor 8% gewijzigd door BastiaanN op 15-07-2008 12:07 ]

[curry684]

Dat was pas 3 keer gezegd

[Verwijderd]

vorlox schreef op dinsdag 15 juli 2008 @ 10:24:
[oef]
en verder je artikelen als serialized array in een DB stoppen is volgens mij niet the way to go
[/oef]

Wanneer je op database-niveau niet hoeft te zoeken/selecteren/filteren op de inhoud van die serialized array, en wanneer je die array ook in de toekomst simpel kunt deserializen is er eigenlijk niks mis mee. Maar een fraai datamodel is 't niet...

DB2, Oracle, MSSQL, etc. ondersteunen ook steeds meer XML structures (vergelijkbaar met die serialized array), waarmee je zelfs met xpath/xquery binnen die XML kunt zoeken, dus misschien is 't voor sommige mensen/toepassingen wel "the way to go"...

[Voutloos]

Verwijderd schreef op dinsdag 15 juli 2008 @ 13:19:
[...]
Wanneer je op database-niveau niet hoeft te zoeken/selecteren/filteren op de inhoud van die serialized array

Zo'n nasty requirement is er in eerste instante nooit, maar pas nadat je app al vergevord is komt opeens de klant aanzetten dat hij alles zoekbaar wil hebben...

Voor sommige log doeleinden, waar de key echt 100% staat, kan het een leuke oplossing zijn, maar in 9 vd 10 gevallen (lage schatting voor de topics op GoT) is het een gruwelijk slecht pan. Dus lekker generaliseren en altijd "BAH! :r" roepen. De expert DBA die het wel nodig heeft die weet wel wanneer hij met dat regeltje moet breken...

BAH!

[kluyze]

probeer eens:

PHP:

$sql = "SELECT * FROM `tb_orders` WHERE sessie='" . $sid . "' AND adreskode='" . $adreskode . "';";
$res = mysql_query($sql);
$num = mysql_num_rows($res);
if($num==0){
  echo "Er zijn geen artikelen toegevoegd";
}else{
  while($row = mysql_fetch_array($res)){
    $order = $row['artikeldrager'];
  }
  $order = unserialize($order);
  echo $num;
  foreach($order as $key => $value){
    echo $key . " = " . $value;
  }
}

Je gaat 2 keer door een loop moeten gaan vanwege de serialized data in de db. Ik vraag me daarnaast trouwens wel af wat je doet als je meer dan 1 rij tegenkomt in je db, nu ga je die namelijk overschrijven.

Trage queries kunnen ook nog al eens te wijten zijn aan het verkeerd gebruiken van indexen of zo, maar ik denk dat het hier niet de query maar de php is die wat trager gaat. Ik neem ook aan dat phpAdmin niet de zelfde lijst geeft als je php script, een bewerking minder geeft ook een snelheidswinst natuurlijk.

[Voutloos]

Je fixed helemaal niets van de hele waslijst eerder genoemde basic problemen, dus laat die code maar. TS heeft genoeg aanknopingspunten om voorlopig eerst even bezig te kunnen zijn.

[kluyze]

Hoezo, hetgeen hier genoemt word kan je niet fixen in de php-code. Daarvoor moet je al een aanpassing van de database voor doorvoeren. Zoals die 2 loops, je kan niet 1 loop elimineren (de eerste gaat als het goed is ook maar 1 keer uitgevoerd worden. De data in zijn database is nu eenmaal zo, de array die er in zit is in string vorm. Dat en de SELECT * zijn de enige dingen die boven komen.

Ik doe een paar overbodige stappen minder die de code opschonen en die voor een minimale snelheidswinst zouden kunnen leiden. En dat is het enige wat kan geoptimaliseerd worden zonder de database aan te passen. Wat volgens mij in dit voorbeeld misschien niet wenselijk is.

[Voutloos]

Geen escaping, nog steeds notices, die mysql_fetch_array() functie call klopt van geen kant, return values worden slecht gecontroleerd (mysql_query() ), het continu opnieuw assignen een bepaalde waarde aan $order slaat als een tang op een varken, etc. etc. zijn allemaal wél basic PHP fouten.

Het datamodel is vast ook niet perfect (lees: mag zeker weten aangepast worden), maar dit script en jouw modificatie zijn eerlijk gezegd gewoon om te grienen.

[ Voor 12% gewijzigd door Voutloos op 15-07-2008 21:18 ]

[Gomez12]

kluyze schreef op dinsdag 15 juli 2008 @ 19:16:
Wat volgens mij in dit voorbeeld misschien niet wenselijk is.

Volgens mij is het juist zeer wenselijk om de dbase aan te passen.

Volgens mij wil je uit een dbase data halen, zorg dan ook dat je er data uit kan halen. Niet dat je nog een 2e bewerking nodig hebt om die data tevoorschijn te halen....

[ACM]

kluyze schreef op dinsdag 15 juli 2008 @ 19:16:
Hoezo, hetgeen hier genoemt word kan je niet fixen in de php-code. Daarvoor moet je al een aanpassing van de database voor doorvoeren.

Het probleem wat hier ontstaat, de maximum executie tijd, heeft niets met de query of database te maken. Maar alles met de while-loop met de quote-loze string die eigenlijk een functie had moeten zijn.

Effectief staat er nu gewoon hetzelfde, maar minder duidelijk, als dit:

PHP:

while($s = 'a string')
{
 // just loop forever
}

Uiteraard zijn de andere genoemde problemen met betrekking tot het ontwerp van de code en de uitwerking ervan ook heel valide. En dat vereist inderdaad wijzigingen aan het datamodel en de manier waarop deze code is opgezet.

[ Voor 15% gewijzigd door ACM op 16-07-2008 08:22 ]

[Voutloos]

En met error_reporting aan en zichtbaar, of met een var_dump($row) binnen de loop vind je dit binnen 5 seconden.

[kluyze]

De "while($row = mysql_fetch_array){" had ik niet aangepast om de simpele redenen dat ik niet weet in wat, ik weet niet wat de variabele is die de TS daar voor gebruikt, en die fout was al opgelost dus neem ik aan dat de TS daar niet nog eens gaat tegenaan lopen. Ik heb er nu ($...) gezet en hoop dat daardoor iedereen tevreden is.

Voutloos schreef op dinsdag 15 juli 2008 @ 20:59:
... return values worden slecht gecontroleerd (mysql_query() ), ...

Als je bedoelt, de valeus die in de query gaan: dat weet je niet aangezien zijn code op regel 75 begint. Als je bedoelt de variabelen die je terug krijgt van de database: dat weet je niet omdat je de rest van de code ook niet hebt. Voorlopig wil hij die ook alleen weergeven en kan hij die zelf wel controleren. Hij vraagt wat het vercshil is met phpAdmin.

Voutloos schreef op dinsdag 15 juli 2008 @ 20:59:
... het continu opnieuw assignen een bepaalde waarde aan $order slaat als een tang op een varken, etc. etc. zijn allemaal wél basic PHP fouten.

Die vraag stelde ik ook als je mijn post goed gelezen hebt, misschien is de TS zeker dat er maar 1 waarde in de database zit, maar dan is die while overbodig. Misschien wil de TS alleen de laatste waarde, maar den is er tenminste een 'ORDER BY' in de query nodig. Maar dit zijn gissingen die de TS alleen ons kan verduidelijken.

Voutloos schreef op dinsdag 15 juli 2008 @ 20:59:
... en jouw modificatie zijn eerlijk gezegd gewoon om te grienen.

Wat is er mis met mijn modificatie om een for() te vervangen met een foreach() en daarbij 2 functies (array_keys() en count()) weg te laten waardoor er een snelheidsverhoging zou kunnen ontstaan?

Mijn opmerking over het design van de database heb ik gemaakt omdat je niet weet hoe de data naar de database geschreven wordt. En dat misschien dit datamodel gekozen is om daar problemen te vermijden.

Het ging de TS dus nog om een klein verschil dat hij leek te merken in snelheid tov phpAdmin _NA_ de aanpassing van de endless loop. Deze snelheid kan niet aan de endless loop liggen (opgelost) en ook niet aan het database design (identieke database), dus aan het parsen van de data waar ik voor de TS een aantal overbodige bewerkingen geschrapt heb.
Je kan natuurlijk verder gaan en kijken naar een index op de table, maar aangezien dat phpAdmin dezelfde tabellen gebruikt kan er ook daar geen snelheidsverschil te merken zijn.

[Zyppora]

kluyze schreef op woensdag 16 juli 2008 @ 10:44:
De "while($row = mysql_fetch_array){" had ik niet aangepast om de simpele redenen dat ik niet weet in wat, ik weet niet wat de variabele is die de TS daar voor gebruikt, en die fout was al opgelost dus neem ik aan dat de TS daar niet nog eens gaat tegenaan lopen. Ik heb er nu ($...) gezet en hoop dat daardoor iedereen tevreden is.

Dat is juist waar het probleem om ging Zonder die extra parameter vormt die while een infinite loop die als conditional statement een assignment heeft ipv. een vergelijking. Hierdoor komt het PHP script met een timeout. PhpMyAdmin maakt geen gebruik van het script van de TS en die geeft dus ook gewoon netjes het verwachte resultaat.

kluyze schreef op woensdag 16 juli 2008 @ 10:44:
[...]
Als je bedoelt, de valeus die in de query gaan: dat weet je niet aangezien zijn code op regel 75 begint. Als je bedoelt de variabelen die je terug krijgt van de database: dat weet je niet omdat je de rest van de code ook niet hebt. Voorlopig wil hij die ook alleen weergeven en kan hij die zelf wel controleren. Hij vraagt wat het vercshil is met phpAdmin.

Wat er tussen die haakjes moet staan is heel duidelijk: een resource result verkregen vanuit een mysql_query aanroep. Ervan uitgaande dat alleen relevante code is gepost, mag je rederlijkerwijs aannemen dat dit de resource result is die verkregen is vanuit de mysql_query aanroep die ook gegeven is.

kluyze schreef op woensdag 16 juli 2008 @ 10:44:
[...]
Die vraag stelde ik ook als je mijn post goed gelezen hebt, misschien is de TS zeker dat er maar 1 waarde in de database zit, maar dan is die while overbodig. Misschien wil de TS alleen de laatste waarde, maar den is er tenminste een 'ORDER BY' in de query nodig. Maar dit zijn gissingen die de TS alleen ons kan verduidelijken.

Niet per se Er zijn meerdere wegen die naar Rome leiden. Waar het om gaat is dat het database model niet erg efficient in elkaar steekt waardoor er nu niet voor de snelste/meest efficiente weg gekozen kan worden.

kluyze schreef op woensdag 16 juli 2008 @ 10:44:
[...]
Wat is er mis met mijn modificatie om een for() te vervangen met een foreach() en daarbij 2 functies (array_keys() en count()) weg te laten waardoor er een snelheidsverhoging zou kunnen ontstaan?

Mijn opmerking over het design van de database heb ik gemaakt omdat je niet weet hoe de data naar de database geschreven wordt. En dat misschien dit datamodel gekozen is om daar problemen te vermijden.

foreach gebruiken om count en array_keys te mogen laten vervallen teneinde een snelheidswinst te bewerkstelligen is achter de komma pas merkbaar, denk ik. Het zal pas bij enorme aantallen iteraties een verschil gaan maken, en dat is hier zeker niet het geval. Daarnaast is het optimization, terwijl er hier daadwerkelijk een probleem geponeerd wordt.

kluyze schreef op woensdag 16 juli 2008 @ 10:44:
Het ging de TS dus nog om een klein verschil dat hij leek te merken in snelheid tov phpAdmin _NA_ de aanpassing van de endless loop. Deze snelheid kan niet aan de endless loop liggen (opgelost) en ook niet aan het database design (identieke database), dus aan het parsen van de data waar ik voor de TS een aantal overbodige bewerkingen geschrapt heb.
Je kan natuurlijk verder gaan en kijken naar een index op de table, maar aangezien dat phpAdmin dezelfde tabellen gebruikt kan er ook daar geen snelheidsverschil te merken zijn.

Dat verschil kun je aan van alles toeschrijven. Misschien zitten er wel dikke loops in de 74 regels code voor deze query uitgevoerd wordt, of worden er zware berekeningen uitgevoerd, of externe bronnen geraadpleegd die niet even snel reageren of zo.

[Voutloos]

kluyze schreef op woensdag 16 juli 2008 @ 10:44:
Als je bedoelt, de valeus die in de query gaan: dat weet je niet aangezien zijn code op regel 75 begint.

Nee, ik bedoel de return values van oa mysql_query(), welke bijv. dus niet altijd een resource terug geeft, slecht worden gecontroleerd.

Wat is er mis met mijn modificatie om een for() te vervangen met een foreach() en daarbij 2 functies (array_keys() en count()) weg te laten waardoor er een snelheidsverhoging zou kunnen ontstaan?

Wat er mis is is dat er klakkeloos allerlei enorm gammele PHP code overgenomen is, ik had niet enkel over je wijzigingen.

Specifiek voor wat betreft je wijzigingen dan: Ik vind dat dus een mooiere code style (subjectief dus), maar het is echt een micro optimalisatie.

Mijn opmerking over het design van de database heb ik gemaakt omdat je niet weet hoe de data naar de database geschreven wordt. En dat misschien dit datamodel gekozen is om daar problemen te vermijden.

Reeds gezegd, in 9 vd 10 is het een verkeerde implementatie. Dat is hier een aanname, maar op basis van gegeven info, lijkt mij dat ook hier van toepasing.

Je kan natuurlijk verder gaan en kijken naar een index op de table, maar aangezien dat phpAdmin dezelfde tabellen gebruikt kan er ook daar geen snelheidsverschil te merken zijn.

Het gaat niet om de tijd van de query, die is niet eens netjes gemeten (want daar zat de timeout ook niet). Dat het daar om gaat staat enkel in de topic title, welke dus niet correct is.

[ Voor 5% gewijzigd door Voutloos op 16-07-2008 11:19 ]

[curry684]

Zyppora schreef op woensdag 16 juli 2008 @ 11:13:
[...]

foreach gebruiken om count en array_keys te mogen laten vervallen teneinde een snelheidswinst te bewerkstelligen is vijf cijfers achter de komma pas merkbaar, denk ik. Het zal pas bij enorme aantallen iteraties een verschil gaan maken, en dat is hier zeker niet het geval. Daarnaast is het premature optimization, terwijl er hier daadwerkelijk een probleem geponeerd wordt.

2 toevoegingen

[pedorus]

kluyze schreef op woensdag 16 juli 2008 @ 10:44:
De "while($row = mysql_fetch_array){" had ik niet aangepast om de simpele redenen dat ik niet weet in wat, ik weet niet wat de variabele is die de TS daar voor gebruikt, en die fout was al opgelost dus neem ik aan dat de TS daar niet nog eens gaat tegenaan lopen. Ik heb er nu ($...) gezet en hoop dat daardoor iedereen tevreden is.

Zie hiervoor: Zoveel regels staan er daarvoor toch niet? Ik zie daar wel degelijk een variabele staan...
Waarom is er bijvoorbeeld een while loop nodig als je een (1) record verwacht? Dan kun je bijvoorbeeld gewoon mysql_result($res,0) gebruiken (als je die '*' ook vervangt).

(Naast dat hier een redesign moet plaatsvinden, waarna de code waardeloos is geworden.)

[kluyze]

Zyppora schreef op woensdag 16 juli 2008 @ 11:13:
Wat er tussen die haakjes moet staan is heel duidelijk: een resource result verkregen vanuit een mysql_query aanroep. Ervan uitgaande dat alleen relevante code is gepost, mag je rederlijkerwijs aannemen dat dit de resource result is die verkregen is vanuit de mysql_query aanroep die ook gegeven is.

Ok, daar heb je me. Ik had even niet verder gekeken als mijn neus lang is (en die is maar kort). Ik heb het aangepast, my bad ...

Maar het datamodel durf ik nog te betwisten, misschien wil de TS dat op een andere plaats niet dat met 1 druk op een knop een query uitgevoerd moet worden voor elke waarde uit een array van 1218 waarden of zo.
Al zou ik als ik van hem was eens kijken naar sessie variabelen opslaan in een database, wat in dit voorbeeld de bedoeling lijkt. Dan doet doet de onderliggende php-code het werk voor hem.
Die oplossing met sessie informatie in de db gaat trouwens ook alle sessie variabelen in een string in 1 veld steken.

@pedorus: Om de laatste van de hoop de vinden misschien? Als je weet dat er 3 waarden in de database zitten waarvan alleen de laatste geldig is dan is dit een mogelijkheid. Al kan je dan best met een ORDER BY in de query werken zoals ik al eerder aanhaalde.

[pedorus]

kluyze schreef op woensdag 16 juli 2008 @ 11:45:
[...]
@pedorus: Om de laatste van de hoop de vinden misschien? Als je weet dat er 3 waarden in de database zitten waarvan alleen de laatste geldig is dan is dit een mogelijkheid. Al kan je dan best met een ORDER BY in de query werken zoals ik al eerder aanhaalde.

Theoretisch is er zonder ORDER BY sowieso niet zoiets als de 'laatste'. Maar dan nog kun je die 3 regels vervangen:

PHP:

  $order = mysql_result($res,$num-1,'artikeldrager');

(NB: vakantietijd blijkbaar, dat hier zoveel reacties op komen )

[curry684]

pedorus schreef op woensdag 16 juli 2008 @ 11:54:
[...]

Theoretisch is er zonder ORDER BY sowieso niet zoiets als de 'laatste'.

Correct voor MySQL, niet correct voor andere databases zoals MSSQL die het concept 'clustered index' hebben.

[Janoz]

curry684 schreef op woensdag 16 juli 2008 @ 11:59:
[...]

Correct voor MySQL.

Het niet definiëren van een volgorde zorgt ervoor dat er ook geen gedefinieerde volgorde is. Dat andere RDBMS ook andere manieren hebben om de volgorde te definiëren doet daar natuurlijk weinig aan af.

[Zyppora]

kluyze schreef op woensdag 16 juli 2008 @ 11:45:
[...]
Ok, daar heb je me. Ik had even niet verder gekeken als mijn neus lang is (en die is maar kort). Ik heb het aangepast, my bad ...

Men leert elke dag iets nieuws

kluyze schreef op woensdag 16 juli 2008 @ 11:45:
Maar het datamodel durf ik nog te betwisten, misschien wil de TS dat op een andere plaats niet dat met 1 druk op een knop een query uitgevoerd moet worden voor elke waarde uit een array van 1218 waarden of zo.
Al zou ik als ik van hem was eens kijken naar sessie variabelen opslaan in een database, wat in dit voorbeeld de bedoeling lijkt. Dan doet doet de onderliggende php-code het werk voor hem.
Die oplossing met sessie informatie in de db gaat trouwens ook alle sessie variabelen in een string in 1 veld steken.

De bedoeling van een database is ervoor zorgen dat je data gestructureerd opgeslagen en opvraagbaar is. Het argument van doorzoekbaar valt al weg in de 'structuur' die de TS gebruikt, terwijl dat gewoon onderdeel is van opvraagbaar. Dat geldt voor data vanuit een andere applicatie, voor arrays met 1218 (of 1218000) waardes, voor sessie variabelen en voor wat dan ook. Dat je die in een andere vorm gebruikt wanneer je ze weer opgevraagd hebt, doet daar niet veel aan af, en de snippet in de TS geeft mooi weer dat er juist hier voor een foute verkeerde opzet is gekozen mbt. de opslag van die gegevens.

Als je rauwe data gevoerd krijgt, zoals een XML bestand, waarin een aantal gegevens staan die je daadwerkelijk wilt hebben, ga je toch ook niet de volledige data in een TEXT veld zetten? Dan ga je dat parsen/ontleden en sla je op wat je daadwerkelijk wilt hebben, en wel in daarvoor op maat gemaakte velden in je tabel.

[curry684]

Janoz schreef op woensdag 16 juli 2008 @ 12:02:
[...]

Het niet definiëren van een volgorde zorgt ervoor dat er ook geen gedefinieerde volgorde is. Dat andere RDBMS ook andere manieren hebben om de volgorde te definiëren doet daar natuurlijk weinig aan af.

Dat is natuurlijk geneuzel in de marge. SQL definieert dat een result set geen sortering bevat indien er geen ORDER BY clause is, maar dat houdt automatisch in dat in dat geval een reeds aanwezige sortering behouden blijft in de result set. En een clustered index in MSSQL definieert nu eenmaal reeds een sortering op table level.

[Voutloos]

Leuk, maar nu doe je of mysql maar 1 engine heeft. Je kan prima een clustered index hebben en het kan geen kwaad om altijd duidelijk te maken wat de volgorde moet zijn.

[curry684]

Voutloos schreef op woensdag 16 juli 2008 @ 12:48:
Leuk, maar nu doe je of mysql maar 1 engine heeft.

Oh geen idee dat er in MySQL ook engines zaten die wel clustered indexen ondersteunen, ik verdiep me niet zo in de talloze pogingen om MySQL beter serieus te nemen maken tot er eentje echt mainstream wordt

Je kan prima een clustered index hebben en het kan geen kwaad om altijd duidelijk te maken wat de volgorde moet zijn.

Daar ben ik het zeker mee eens: als je al een clustered index op date descending of zo hebt is er niets mis mee om er alsnog een ORDER op te doen zodat je iig niet afhankelijk wordt van je DDL, en laat de optimizer maar uitzoeken dat die query pokkesnel is omdat die sortering er al ligt

[Voutloos]

curry684 schreef op woensdag 16 juli 2008 @ 13:00:
Oh geen idee dat er in MySQL ook engines zaten die wel clustered indexen ondersteunen, ik verdiep me niet zo in de talloze pogingen om MySQL beter serieus te nemen maken tot er eentje echt mainstream wordt

Van mij hoef je geen mysql guru te worden, als je maar weet/stelt dat niet elke engine pover is. InnoDB doet al jaren veel goed en is voor iedereen die uberhaupt op de gebruikte engine let wel zeker de default/gebruikelijke optie (transacties, row level locking, clustered index, etc. etc.)

[curry684]

Jammer alleen dat de meeste serieuze applicaties die echt baat hebben bij goede locking en transactions ook een dringende noodzaak hebben aan full text search. Maar gelukkig heeft de lead developer de verwachting dat het er in januari 2006 zal zijn!

[Voutloos]

Er wordt nu vooral gewerkt aan opvolgers van InnoDB.

(en full text search zuigt uberhaupt qua performance kamelenballen zodra je meer dan 100k rows hebt. Het is een black box en de optimizer (houd je in met die inkopper aub ) moet per se de FT index gebruiken. Sphinx FTW!)
En nu kap ik met de mysql speaker uit te hangen.