[MySQL] paginazione tramite Stored Procedure

[newbobotime]

Ciao Raga urge aiutino

Mi piacerebbe utilizzare una SP che mi aiuti nella paginazione, ho letto qualcosa online ma sinceramente non riesco a metterla in pratica.

questo è uno dei tanti link: paginazione dei risultati con stored procedure

Ammesso che riesca a generare la mia SP, con tanto di conteggio delle righe (FOUND_ROWS()), sinceramente non ho capito come richiamarla da php e generare la conseguente numbers bar ( << 1 2 3 >> )

qualcuno ha qualcosa di pronto da adattare, oppure mi spiega come richiamare da php la SP in modo da generare i link previous and next ?

10x



.

[franzauker2.0]

1) mi pare del tutto inutile
2) il link php generato da una SP?
3) attenzione che la paginazione ottenuta con LIMIT X,Y è inerentemente inefficiente su MySQL. Va bene per progettini non molto trafficati

Riguardo al link che hai messo il tipo non ha una gran dimestichezza coi DB, e mysql in particolare, addirittura rimanda ad un altro post (vecchio per la verità) che parla di tutt'altro

In sostanza la domanda è se è più veloce fare due query per avere un certo dataset, e sapere quanto è grande (il numero delle righe), oppure scrivere una SP che ritorni entrambe le informazioni.

In php, per la verità, il numero delle righe tornate esiste già, quindi il problema non si pone.

Ad ogni modo la conclusione è il contrario
So, obvious conclusion from this simple test is: when we have appropriate indexes for WHERE/ORDER clause in our query, it is much faster to use two separate queries instead of one with SQL_CALC_FOUND_ROWS. del suggerimento dell'utilizzo delle SP

Francamente non ho una grandissima voglia di approfondire il tema, perchè parte da un presupposto errato in radice, ovvero che sia "buona cosa" usare in generale le SP su MySQL.
Il supporto è pessimo, e sono state introdotte come "necessità per fare i fichi", è un mondo diametralmente opposto ad altri RDBMS ove invece sono usatissime (e spesso utilissime)

[newbobotime]

Uhm.... ,
Quindi secondo te le SP su MySQL non hanno alcun senso di esistere ? A parte per i fighi in qestione !

Mah... secondo il mio modesto punto di vista (per carità, non mi ritengo di certo un grande esperto) in determinati contesti aiutano e parecchio, ma in particolare mi soffermerei sui vantaggi che offrono che sono di gran lunga superiori agli svangtaggi, ovviamente non mi dilungo ad elencarli.

Comunque ho capito che dal tuo punto di vista, non ha senso implementare una stored procedure per gestire la paginazione.

C'è per caso qualcuno che la pensa diversamente da franzauker2.0




.

[franzauker2.0]

Originariamente inviato da newbobotime
...mi soffermerei sui vantaggi che offrono che sono di gran lunga superiori agli svangtaggi, ovviamente non mi dilungo ad elencarli.

Soffermati... soffermati... dilungati... dilungati...

[optime]

@franz, tanto per capire, come mai le SP (che io uso a vagonate in M$SQL) in MySQL non andrebbero così bene?

[franzauker2.0]

Originariamente inviato da optime
@franz, tanto per capire, come mai le SP (che io uso a vagonate in M$SQL) in MySQL non andrebbero così bene?

Se hai un attimo di pazienza vedrai che l'utente spiegherà i notevoli vantaggi delle SP in MySQL.
Spiegare il perchè e il percome richiederebbe partire da un po' lontano, tipo come è nato mysql, perchè è stato fatto così, come si è sviluppato, come è fatto ora, perchè è fatto così, e magari come è stato fatto mssql, oracle, db2, e perchè son diversi da mysql e perchè...

Comunque tranquillo, confido in qualche esperto che faccia chiarezza.

[optime]

Originariamente inviato da franzauker2.0
confido in qualche esperto che faccia chiarezza.

fai sempre il finto tonto ma va bene così, ti si vuole bene lo stesso

comunque, in soldoni, per via della natura di MySql tu sconsigli l'uso delle SP; credevo invece che - pur avendole introdotte *tardissimo* - avessero fatto le cose per bene e fossero performanti (e risolutive/indispensabili in certi casi) come per altri db

[franzauker2.0]

Originariamente inviato da optime
fai sempre il finto tonto ma va bene così, ti si vuole bene lo stesso

comunque, in soldoni, per via della natura di MySql tu sconsigli l'uso delle SP; credevo invece che - pur avendole introdotte *tardissimo* - avessero fatto le cose per bene e fossero performanti (e risolutive/indispensabili in certi casi) come per altri db

La storia di mysql è fondamentale per capire cosa fa e come e cosa no.
Visto che non interessa a nessuno, con riferimento alle SP, esse non sono mai state ritenute qualcosa di utile: anche l'integrità referenziale è stata per tantissimo tempo snobbata, aggiunta solo dalla versione 5.1.
E, per la verità, ancora oggi è supportata davvero poco; altre cose tipo i check semplicemente... non esistono e così via.

Con riferimento alle SP esse, ovviamente, non esistevano fino alle "ultime" versioni di mysql, per banali ragioni di complessità.
Troppo difficile implementare qualcosa di così complicato,e quindi sono sempre state banalmente "appiccicate" al codice solo per poter dire "noi ciabbiamopureerrstorrreeddd".

Guardando la struttura di mysql si capiscono tante cose, ma di nuovo non approfondisco.

Tornando alle SP e perchè non sono particolarmente utili, nè utilizzate, in mysql i motivi sono vari, il principale è che, semplicemente, non son state mai sviluppate ed integrate bene.
Ciò implica che i progetti storici non li utilizzino, se non in misura risibile, perchè tra l'altro hanno prestazioni davvero basse.

Inoltre c'è anche una motivazione tecnica sulle sessioni: mentre in mysql il protocollo di connessione è leggerissimo (e insicuro), in altri DB esso è pesantissimo.

In sostanza un ciclo del tipo
... fai 1000 chiamate a mysql per eseguire 1000 query..., paradossalmente, ha un overhead che è (spesso) più basso di
- crea un SP che internamente fa le 1000 query, e chiamala una sola volta (qui si apre poi tutto il discorso della cache di mysql, e anche della modalità di hashing per stabilire il riutilizzo dei dati blablabla)

In MSSQL (ed altri) ciò non accade: il "costo" delle sessioni è talmente elevato che risparmiarle dà un vero vantaggio, e inoltre... semplicemente sono fatte meglio, molto meglio (soprattutto sotto il profilo del debugging).
C'è poi tutto un casino (gigantesco) sulla replicazione a statement, motivo già di per sè sufficiente nella stragrande maggioranza dei casi di fanculizzarle direttamente, tanto che nelle ultime versioni vengono scritte nel binary log addirittura le singole query e non la procedura (!!), ma comunque richiedendo sempre il row-based per un minimo di affidabilità.

Riguardo poi all'impatto sulle prestazioni, posto che come detto mysql è sempre in divenire e ciò che si dice oggi potrebbe non valere più domani, il "piccolo" problema è che l'ottimizzatore di mysql (rif agli internals per chi è curioso di vedere come opera) non può semplicemente stimare quanto costerà la Stored,
e questo è male.
Sotto il profilo della cache ogni connessione ha la sua pianificazione: se le connessioni chiamano la stessa stored (cosa comune) lo stesso piano viene duplicato per ogni chiamata.
Computazionalmente poi sono pessime (le SP di MySQL, quelle ad esempio di MS sono decisamente più veloci).

Insomma sono adatte essenzialmente per piccolissime funzioni che vengono eseguite in loop, cosa che in generale è comunque da evitare (il loop intendo) con una buona progettazione.

Nella mia esperienza (tra l'altro rammento vagamente un thread del genere, in OT) per MySQL vengono usate diffusamente quando si vuole... fare un accesso "a oggetti" (per modo di dire) al database.
Ovvero scrivendo delle SP che fanno qualcosa (aggiungi record, cancella record e così via), senza che l'utente della connessione possa accedere direttamente al db.

Perchè fare ciò? Per sicurezza, li ho visti usare in ambito bancario ed assicurativo, in maniera che un eventuale "birichino" non potesse alterare i db a suo piacimento, ma solo attraverso queste "interfacce" (che loggavano ovviamente i comandi, in un caso addirittura stampandoli su carta a modulo continuo!)


Cosa succede però? Che chi non conosce MySQL dice "fico, ci sono le SP, queste sono buone e giuste, su Oracle ci ho scritto anche Pacman, allora iniziamo ad usarle", o parimenti, lo insegna ai suoi studenti

MySQL è un coacervo di tante idee diverse, e pure codice, che sono stati "ammucchiati" più o meno disorganicamente nel corso di un 15 anni di sviluppo. Tante di queste sono appiccicate lì o poco più, molte fanno a "cazzotti" con le altre.

[in the web]

Su alcune cose non sono molto d'accordo, ma anche per evitare le solite discussioni mi interessava approfondire solo un aspetto che Frankauzer ha toccato di striscio: il debug.

Esistono ovviamente dei debugger, ma non potendo contare su nessun tipo di libreria nativa, sono degli hack o degli emulatori. E cioè:
* o iniettano nelle tue stored routine del codice SQL che fa il debug, senza fartelo vedere
* o eseguono loro stessi le stored routine, al posto di MySQL

La prima tecnica è descritta qui:
http://web.archive.org/web/201205080...oredProcedures
(Per la cronaca sono costretto a linkarla su webarchive perché Oracle ha eliminato diverse risorse su MySQL. Che, tanto per precisare, erano frutto degli sforzi della comunità, non suoi.)

Semplificando al massimo: nessuna delle due tecniche è affidabile, perché per debuggare hai bisogno di ricreare esattamente le stesse condizioni che si verificano durante un'esecuzione normale. Nel primo caso questo non succede perché esegui del codice diverso da quello originale. Nel secondo caso non succede perché il codice server non è quello di MySQL ma quello del debugger.

Ritengo che la prima tecnica sia comunque la più affidabile, perché la seconda non può riprodurre i bug di MySQL e i comportamenti specifici (a volte non documentati) di tutte le singole versioni.

Qualcuno potrebbe accorgersi che Oracle ha un debug e pensare che questo sia nativo. Allora precisiamo: anche quello è un misero hack o poco più, addirittura NON è tra i migliori, e gira solo su Windows.

[in the web]

Ho avuto un po' da fare, torno sul forum e vedo che questo 3d è ancora in prima pagina. E mi viene in mente una stored procedure che ho visto stamattina. Ve la linko perché è interessante (se qualcuno non la capisce, e se interessa, provo a spiegarla)

https://code.google.com/p/common-sch...pby&sort&id=44