Ho un'architettura REST, che esegue PHP sul lato server che memorizza e interrogare un database Mysql.
Sto rivalutando una decisione sul design dell'architettura:
DECISION per rivalutare:
Nel tentativo di evitare le comunicazioni avanti e indietro tra PHP e Mysql:
-
Per alcune richieste del browser (ad esempio: "GET / sessions / 4"), una richiesta richiede una risposta importante con i collegamenti degli oggetti correlati.
-
Per queste situazioni, ho progettato alcuni grandi mysql memorizzati procedure per interrogare più tabelle. Pertanto, per una richiesta del browser, PHP avvia questo MySql memorizzato procedura che esegue. Alla ricezione dei risultati PHP, il mio codice PHP passa attraverso ogni pacchetto di risultati della query per creare oggetti e collegarli logicamente.
-
Al termine di questo processo, PHP interroga i miei oggetti di visualizzazione logica interni per costruire la risposta formattata restituita alla richiesta del browser.
-
L'alternativa sarebbe quella di richiedere più stored procedure e avviarle ognuna in PHP anziché all'interno di questa stored procedure.
PROBLEMI : Diventa piuttosto difficile gestire i cambiamenti nel tempo. Queste stored procedure diventano difficili da mantenere, poiché ogni tabella cambia, hanno un impatto su una di esse.
DOMANDA : Ho iniziato questo progetto, perché molti framework generati dal codice vengono criticati per la loro mancanza di efficienza nella comunicazione tra il livello PHP e Mysql. Effettuando quelle stored procedure a mano, mi aspettavo di avere le migliori prestazioni in produzione, tuttavia, la manutenzione inizia a essere fastidiosa. L'architettura ad alta efficienza della vita reale tenta di limitare il numero di comunicazioni PHP (Mysql stored procedure) avanti e indietro o sto tentando di circondare un falso problema ???
Grazie