2009-05-01 1 views
6

Gestisco un sito Web per un grossista di gioielli.MySQL Stored Procedure vs PHP script

I prezzi di tutti i loro prodotti sono calcolati utilizzando le attuali correzioni di metalli preziosi che vengono aggiornate ogni notte.

Attualmente, per il sito Web, i calcoli vengono elaborati tramite una funzione di inclusione di php, che funziona correttamente nelle circostanze attuali.

Ci sono circa 10.000 prodotti, ma i prezzi sono calcolati in tempo reale (cioè quando viene richiesta la pagina web). I calcoli sono semplici, ma ce ne sono molti (circa 50+) e temo che un aumento del traffico possa rallentare lo script corrente.

Sto riprogettando il sito e mi chiedevo se sarebbe stato utile creare una procedura in MySQL per eseguire i calcoli.

È probabile che sia più veloce rispetto all'attuale script php? Qualcuno conosce un buon riferimento alla lettura sull'uso delle procedure?

+0

Grazie per tutti i commenti e collegamenti. Penso che prenderò l'approccio "Se non è rotto, non aggiustarlo" considerando i futuri mal di testa di cambiarlo. – ticallian

+2

Per chi ha downvoted la mia risposta, può spiegare perché? Credo che sia una risposta valida. – Unknown

risposta

4

Se la ragione per cui si sta pensando a questo è dovuta a prestazioni e scalabilità, quindi suggerirei di continuare il calcolo in PHP.

La ragione di ciò è che indipendentemente dal fatto che ci sia una penalità di prestazioni nel PHP, quando si ridimensiona l'applicazione Web è generalmente molto più semplice spostarsi su più server Web rispetto a più server di database. È quindi preferibile fare più calcoli in PHP e meno in MySQL.

A parte l'aspetto delle prestazioni, sono ancora generalmente preferiscono evitare stored procedure a favore di avere la logica nell'applicazione perché

  • Può essere meno portabile. La stored procedure si aggiunge all'impegno richiesto per distribuire una nuova istanza dell'applicazione.
  • Sono scritti in una lingua diversa da PHP, quindi uno sviluppatore PHP potrebbe non trovarli facilmente comprensibili.
  • Può essere difficile mantenerli nel controllo del codice sorgente.

Questi problemi possono naturalmente essere risolti, senza un'enorme difficoltà, se si desidera utilizzare stored procedure.

10

Ecco un punto di riferimento con stored procedure vs php.

http://mtocker.livejournal.com/45222.html

La stored procedure è stato più lento di 10 volte.

Si potrebbe anche voler guardare a questo:

http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html

+1

Non so perché questo è stato downvoted. Sono tuttavia scettico sull'accuratezza di quel benchmark. – thomasrutter

+0

Non lo so nemmeno, sono stato downvoted tutto il giorno per risposte legittime. – Unknown

+4

ho visto questo problema. alcune persone vogliono solo downvotare i commenti, o possono essere occasionalmente cliccano quando non lo desiderano. Mi piacerebbe se SO costringesse l'utente a lasciare commenti sul motivo per cui post o commenti sono stati downvoted. Il downvoting dovrebbe aiutare l'altra persona a migliorare e non dovrebbe essere un modo per sfogare la frustrazione di qualcuno. –

3

Se è assolutamente necessario aggiornare i prezzi su ogni richiesta della pagina e siete preoccupati che il sito sarà sempre un sacco di traffico Non consiglierei le stored procedure.

Suggerirei di memorizzare nella cache le informazioni che usi (ed è difficile elaborare senza sapere come stai facendo) in memoria (magari usando memcached) e continuate a leggerlo da PHP.

Devo ammettere che non ho eseguito alcun benchmark tra le stored procedure e le prestazioni PHP in memoria ma se la procedura non influisce direttamente sulla query, raccomando la memorizzazione nella cache.

+0

bel suggerimento sull'utilizzo di memcached – thomasrutter

2

In breve, tienili in php. Più semplice da mantenere.

Per il sito corrente, è improbabile che si verifichi un problema di prestazioni in cui la differenza tra la velocità di calcolo in php e la velocità del calc nel database è sempre evidente. Se tu fossi allora, c'è qualcosa di fondamentalmente sbagliato nel codice del sito. (Questo include le conversioni di valuta in tempo reale se fatto).

Detto questo, di solito si preferisce mantenere il calcolo in PHP in quanto è più facile da controllare e eseguire il debug. Richiede ai programmatori web di conoscere un po 'il database, ma normalmente non è un problema. Il 90% degli aumenti di velocità del codice si verifica sul 10% del codice e sarebbe abbastanza facile per un dba identificare le query che causano il caricamento di db se mai accadesse.