[MySQL naar XML]PHP Automatisch logische structuur van query

[r0bert]

Weet niet of het mogelijk is wat ik wil, want heb het gevoel dat het erg veel performance kost. Maar wat ik graag zou willen bereiken, is dat ik een MySQL, voor het gemak gebruik ik even SQL, query uitvoer, en deze dan automatisch een XML document teruggeeft in een logische structuur.

Op het moment doe ik het op deze manier:

PHP:

$oVeiling = 
    $this->oModule->appendChild(
        $this->oDoc->importNode(
            
            mysqltoxml(
            
                'SELECT *, AVG(`intCijfer`) `intBeoordeling`
                    FROM `tblVeilingen` `tblV`, `tblVeilingBeoordelingen` `tblB`
                        INNER JOIN `tblUsers` `tblU` ON `tblV`.`intAanbiederId`     = `tblU`.`intId`
                        INNER JOIN `tblUserInfo` `tblUI` ON `tblV`.`intAanbiederId`     = `tblUI`.`intUserId`
                    GROUP BY `tblV`.`intVeilingId`'
                ,
                
                'veiling',
                
                Array(
                    'intVeilingId'      => 0,
                    '___aanbieder'      => Array
                    (
                        'intAanbiederId'    => 0,
                        'varVoornaam'       => 0,
                        'varAchternaam' => 0,
                        'varUser'           => 0,
                        'varEmail'      => 0,
                        'lastAct'           => 0,
                        'intBeoordeling'    => 0
                    ),
                    '___looptijd'       => Array
                    (
                        'dtmDatumStart' => 0,
                        'dtmDatumEind'      => 0
                    ),
                    'varTitel'      => 0,
                    'txtOmschrijving'   => 0,
                    'enuType'           => 0
                )
                
            )->firstChild,
            
            true
        )
    );

Wat op zich prima werkt, alleen moet ik dan bij iedere query, het XML document zelf opmaken, hier adhv Arrays. Liever zou ik zien dat PHP aan de hand van mijn Query of een DESCRIBE result van mijn SQLdb een logische structuur maakt. Dus dat ie kijkt wat ik gebruik als index en wat er gejoined wordt. Dan de joins als childs invoegen en de primary index als attr. etc..

Alternatieven om dit te bereiken zou ik ook heel interessant vinden. Heb al een tijdje gezocht, maar kwam niet uit op wat ik probeer te bereiken.

edit:
sorry voor de rare inspringen e.d.

[ Voor 19% gewijzigd door r0bert op 03-01-2006 16:03 ]

[Bosmonster]

Uiteindelijk krijg je toch alleen records terug, onafhankelijk van joins, subquery's, etc. Het is niet zo heel lastig om door een resultset heen te lopen en daar een gestandaardiseerde xml van te maken?

[ Voor 8% gewijzigd door Bosmonster op 03-01-2006 16:12 ]

[r0bert]

Nadeel nu is dat ik voor iedere query handmatig de structuur op moet geven..
Liever zou ik bij de query hierboven bijv hebben dat PHP "automatisch bedacht" dat User gelinked is aan intAanbieder en dat ie daar dus een aparte child van maakt (bijv aanbiederinfo) en daar de informatie van de informatie inplant.

Nu is het wel makkelijk om gewoon alle info van de records onder een eigen row te plakken in het XML resultaat. Echter wil ik er wat meer structuur in want de voornaam en achternaam vind ik niet direct onder het veiling element horen

Maar misschien bedoel jij met gestandaardiseerde xml, waar ik naar op zoek ben? Of bedoel je gestandaardiseerd als in handmatig vooraf opgesteld?

edit:

Even voor duidelijkheid nog, bovenstaande werkt dus verder prima hoor, heb ik ook uitgewerkt. Ik zou echter het derde argument van mysqltoxml weg willlen laten en xml zelf iets soortgelijks willen laten genereren representatief voor de relaties in de query/database

[ Voor 18% gewijzigd door r0bert op 03-01-2006 16:20 ]

[r0bert]

Iemand nog ideeën / ervaringen?

[djluc]

Je kan toch gewoon handmatig je join parsen?

[JHS]

djluc: Ja, maar hij wil het automagisch laten doen...

r0bert: Eerlijkgezegd denk ik dat het wel kán, maar dat je toch echt zélf een parser moet schrijven welke de sql query neemt, en ombouwt tot een formaat waarin door een andere parser de geretourneerde data kan worden gepropt. Iets wat me een hele hoop werkt lijkt .

[djluc]

@JHS: jij zegt toch gewoon precies hetzelfde als ik zeg? Je parsed de query waardoor je de relaties er uit kunt halen. * djluc ziet het verschil niet...

[JHS]

djluc: Handmatig impliceert voor mij het idee dat je pér join / query met de hand de code moet ombouwen tot de code welke de "2e" parser gebruikt om de geretourneerde waardes in te frotten, in tegenstelling tot automatisch, waarbij je "elke" query erin kan stoppen. Maar dat bedoelde je kennenlijk niet .

[r0bert]

Hoe weet ik nou welke velden uit het resultaat bij welke join table horen dan? Ik snap niet hoe jullie dat klaar willen spelen zonder info van de table zelf?

[djluc]

Als je nou een query hebt als:

SELECT table1.field, table2.field FROM table1 INNER JOIN table2 ON table1.joinfield=table2.joinfield

PHP:

$sql="SELECT table1.field, table2.field FROM table1 INNER JOIN table2 ON table1.joinfield=table2.joinfield";
$sql=str_replace('SELECT ', '', $sql);
$exp1=explode($sql, 'FROM');
$fields=explode($exp1[0], ',');
//enzovoorts

[r0bert]

Ik heb als resultaat van mijn query:

SQL:

SELECT *, AVG(`intCijfer`) `intBeoordeling` 
     FROM `tblVeilingen` `tblV`, `tblVeilingBeoordelingen` `tblB` 
         INNER JOIN `tblUsers` `tblU` ON `tblV`.`intAanbiederId` = `tblU`.`intId` 
         INNER JOIN `tblUserInfo` `tblUI` ON `tblV`.`intAanbiederId` = `tblUI`.`intUserId` 
    GROUP BY `tblV`.`intVeilingId`

mysql_fetch_array($sqlrsl)

PHP:

Array(
   'intVeilingId' => 'waarde',
   'intAanbiederId' => 'waarde',
   'dtmDatumStart' => 'waarde',
   'dtmDatumEind' => 'waarde',
   /* ..etc..etc.. */
   'datGeboorte' => 'waarde',
   'varBuurt' => 'waarde',
   'varMsn' => 'waarde',
   'txtBericht' => 'waarde',
   'intBeoordeling' => 'waarde',
)

Ik weet niet precies hoe jij bovenstaande voorbeeld hierop toe wilt passen, aangezien je niet weet welke velden van welke table komen, en dus ook niet van welke join.. toch?

[ Voor 109% gewijzigd door r0bert op 04-01-2006 23:38 ]

[JHS]

Smerig: noem je kolommen tabelnaam_kolomnaam . Verder kan je de gegevens van een tabel oproepen, waardoor je zou kunnen voorspellen welke kolomnaam bij welke tabel hoort, en aangezien de volgorde waarin de gegevens gejoined worden volgens mij ook voorspelbaar is, zou dat moeten werken, lijkt mij. Alleen zou ik dan in een productie omgeving niet per request je database gaan mappen, maar het resultaat van die mapping cachen .

[Bosmonster]

r0bert schreef op dinsdag 03 januari 2006 @ 16:17:

Nu is het wel makkelijk om gewoon alle info van de records onder een eigen row te plakken in het XML resultaat. Echter wil ik er wat meer structuur in want de voornaam en achternaam vind ik niet direct onder het veiling element horen

Dat bedoel ik dus. Dat maakt imho niet uit. Uiteindelijk geeft een query altijd 'platte' records terug van data die bij elkaar hoort. Een veiling item, de gebruiker die op dat item geboden heeft en bijvoorbeeld het hoogste bod heeft (ook al komt het uit verschillende tabellen), hoort in die record bij elkaar.

Tuurlijk kun je heel ingewikkeld gaan doen en je query parsen etc, alleen maar voor een iets andere xml opmaak, maar persoonlijk zou ik het nogal zonde van mn tijd vinden.

[r0bert]

JHS schreef op donderdag 05 januari 2006 @ 16:23:
Smerig: noem je kolommen tabelnaam_kolomnaam .

smerig?

Verder kan je de gegevens van een tabel oproepen, waardoor je zou kunnen voorspellen welke kolomnaam bij welke tabel hoort, en aangezien de volgorde waarin de gegevens gejoined worden volgens mij ook voorspelbaar is, zou dat moeten werken, lijkt mij.

Dus dan toch de describe die ik in het begin noemde Was ook mijn enige oplossing die ik kon bedenken

Alleen zou ik dan in een productie omgeving niet per request je database gaan mappen, maar het resultaat van die mapping cachen .

Dat is inderdaad het overwegen waard. Weet niet of het zoveel sneller is, maar belast mijn databaseserver in ieder geval al weer minder .. thnq

Bosmonster schreef op donderdag 05 januari 2006 @ 16:57:
[...]


Dat bedoel ik dus. Dat maakt imho niet uit. Uiteindelijk geeft een query altijd 'platte' records terug van data die bij elkaar hoort. Een veiling item, de gebruiker die op dat item geboden heeft en bijvoorbeeld het hoogste bod heeft (ook al komt het uit verschillende tabellen), hoort in die record bij elkaar.

Maar alle biedingen, wil je niet onder een veiling record hangen, dat wil ik tenminste wel weer graag onder een record 'bieders' (zoals het dus ook uit de tables/database komt). Voor mij is het even de afweging of dat makkelijk te bereiken is.. Als daar een methode voor is, scheelt dat me later veel tijd. Laat ik een query los op mijn database, en krijg ik een net XML bestand terug.

Die structuur is niet alleen voor hoe het eruit ziet/aanvoelt als XML, maar ook vooral voor de XSL. Daar is een lekkere structuur natuurlijk veel fijner om mee te werken (de templates)

Tuurlijk kun je heel ingewikkeld gaan doen en je query parsen etc, alleen maar voor een iets andere xml opmaak, maar persoonlijk zou ik het nogal zonde van mn tijd vinden.

Ach, ik zie het maar als een investering En de tijd die het kost om te parsen, is niet zo heel erg van belang eigenlijk, want de XML wordt gewoon daarna opgeslagen in bestand en die wordt door de gebruiker opgevraagd. Wordt er wat gewijzigd, dan wordt bovenstaande stap gewoon opnieuw uitgevoerd. Ach je snapt het wel


Ik denk dat ik de handmatig manier gewoon optioneel open laat, als die niet gespecificeerd is, pakt PHP maar de describe erbij en vogelt ie het uit.

[ Voor 52% gewijzigd door r0bert op 05-01-2006 17:17 ]

[Bosmonster]

r0bert schreef op donderdag 05 januari 2006 @ 16:58:

Maar alle biedingen, wil je niet onder een veiling record hangen, dat wil ik tenminste wel weer graag onder een record 'bieders' (zoals het dus ook uit de tables/database komt). Voor mij is het even de afweging of dat makkelijk te bereiken is.. Als daar een methode voor is, scheelt dat me later veel tijd. Laat ik een query los op mijn database, en krijg ik een net XML bestand terug.

Die structuur is niet alleen voor hoe het eruit ziet/aanvoelt als XML, maar ook vooral voor de XSL. Daar is een lekkere structuur natuurlijk veel fijner om mee te werken (de templates)

Alle biedingen? Ik neem aan dat je die niet samen met de veilingen bijvoorbeeld in 1 query ophaalt? Anders heb je wel heel veel dubbele gegevens in je recordset. Doe je het in meerdere query's dan heb je een wat ander probleem dan je beschrijft?

[ Voor 6% gewijzigd door Bosmonster op 06-01-2006 14:18 ]

[JHS]

r0bert schreef op donderdag 05 januari 2006 @ 16:58:
[...] smerig?

Nuja, het 'voelt' voor mij niet goed. Maar het zo het wel oplossen, lijkt me, op een redelijk simpele manier .

[r0bert]

Bosmonster schreef op vrijdag 06 januari 2006 @ 14:17:
[...]


Alle biedingen? Ik neem aan dat je die niet samen met de veilingen bijvoorbeeld in 1 query ophaalt? Anders heb je wel heel veel dubbele gegevens in je recordset. Doe je het in meerdere query's dan heb je een wat ander probleem dan je beschrijft?

Mmm doe het inderdaad in 1 query omdat ik het idee had dat dan een minder zware belasting voor de sqlserver zou zijn, maar da's dus niet zo begrijp ik dat je suggereerd