MySQL - Recursieve stored function

Na 3-4 lezen snap ik em :)

Maar wat is het voordeel van dit over gewoon een functie schrijven in PHP?
MySQL lijkt me niet echt geschikt om functies in te maken... ik gebruik het liever waarvoor het gemaakt is: data ophalen.

Toch is het best handig om te weten dat SQL/MySQL zoveel kan, maar het lijkt me een beetje onnodig.

Onnodig is het zeker niet. In performance opzicht zijn stored routines erg gemakkelijk. Je wilt tenslotte je data zo verwerkt mogelijk uit je database halen.

MySQL is zeker wel geschikt voor functies / procedures, waarom denk je anders dat ze erin zitten? (sinds versie 5)

http://nl.wikipedia.org/wiki/Opgeslagen_procedure

@Toby: Wanneer je met grote hoeveelheden data werkt, wil je die zooi echt niet eerst uit de database halen, dan bewerken en vervolgens weer terug gaan zetten. Daar zitten de grootste voordelen van stored procedures maar ook veiligheid en eenduidigheid zijn belangrijk. Iedere applicatie, in welke taal dan ook, kan van de functie in de database gebruik maken. Je hoeft dus niet iedere keer opnieuw het wiel uit te vinden.

Bedankt voor de heldere toelichting Frank! Ben het volledig met je eens.

Je wilt niet al in je query een "-" toevoegen. Dat wil je pas op het moment dat je het wilt tonen op het scherm van de gebruiker. Op deze manier krijg je verkeerde data terug uit je database, als je het opslaat met de waardes zoals je ze ophaalt.

Zie ik daar nou backticks? ...

@pgFrank, dat je dat niet eens zag!

@iltar van der berg;

Maar dat doe je nou toch helemaal niet? De data gaat gewoon 'goed' de database uit. En wil je je data onverwerkt eruit halen doe je: SELECT category.name etc..

In mijn ogen moet je MySQL zoveel mogelijk laten doen qua data presentatie en PHP qua HTML opmaak.. Overtuig me als het niet zo is.

Een database moet data opslaan, beschermen (doet MySQL niet!), bewerken en beschikbaar stellen. Presentatie hoort een database niet te doen en kán een database ook helemaal niet doen. De database heeft geen flauw idee hoe je iets wilt presenteren en soms wil je iets op tien verschillende manieren kunnen presenteren (email-text, email-html, html-fullscreen, html-mobiel, etc. etc.). Wil je dan ook 10 verschillende functies gaan maken? Lijkt mij niet.

Het zou dus vele malen handiger zijn wanneer je gewoon de plek in de data-boom aangeeft, het niveau. niveau 1, niveau 2, etc. Of maak er een boomstructuur van in XML, kun je het resultaat eenvoudig gaan presenteren met XSLT en/of CSS. Die zijn namelijk gemaakt voor presentatie, databases en XML zijn niet gemaakt voor presentatie, browsers kletsen niet eens rechtstreeks met jouw database, daar zit al een laag tussen.

De huidige opzet kan alleen maar - presenteren, voor alle andere presentaties zul je het aantal minnetjes moeten gaan tellen en deze met een regex gaan vervangen door de gewenste presentatie. Zeer omslachtig en alles behalve flexibel.

Verder zou ik MySQL zo min mogelijk laten doen, maar dat staat los van dit script en ga ik verder niet op in.

@Mebus: Die vieze vuile gore volslagen idiote backticks komen waarschijnlijk uit een rottige tool, vandaar dat ik daar maar niets over heb gezegd.

@pgFrank, PHPmyadmin dus:...

Nee, MySQL Query Browser ;)

Overigens gedeeltelijk ben ik het wel met je eens Frank, niet helemaal. Maar ik ga er niet verder op in om een oneindige discussie te voorkomen in dit script.

@kees
Precies wat ik zei dus.

Ik vind nog steeds dat de database bedoeld is voor het ophalen van data en niet voor het bewerken ervan.

Kleine conversie, owke... maar complete functies?
Maar ik zal dit zeker in mijn achterhoofd houden bij productie van mijn scripts. Ik ga nog wel wat rond lopen testen met dit soort mogelijkheden.

Normaal gebruik ik een PHP classe voor het ophalen en bewerken van de data. Als ik de data moet omzetten voor gebruik en/of groot aantal rijen verwacht, maak ik gebruik van een unbuffered query: Terwijl de DB bezig is met de data is PHP al bezig met het omzetten ervan.