Su un sito con una quantità ragionevole di traffico, sarebbe importante se la logica dell'applicazione/business fosse scritta come stored procedure, trigger e viste, invece che all'interno del codice PHP stesso?Business Logic in PHP o MySQL?
Quale sarebbe il modo migliore per tenere a mente la scalabilità.
Non sono in grado di fornire statistiche, ma se non si prevede di cambiare PHP in un'altra lingua in futuro, posso dire che mantenere la logica di business in PHP è più "scalabile".
È sempre più facile e meno costoso risolvere i problemi di caricamento del server Web rispetto al loro inserimento nel database. Il tuo database avrà sempre bisogno di essere illuminato rapidamente e il solo lancio di specchi non risolverà il problema. Maggiore è il numero di slave del database, più è necessario scrivere.
+1 .. Sì, questo è esattamente quello che stavo pensando ... posso bilanciare il carico PHP, ma come bilanciare il bilanciamento di MySQL. –
Un'applicazione PHP ben fatta dovrebbe essere sufficiente, ma tieni presente che richiede anche che tu faccia meno chiamate al database che puoi. Memorizza i valori necessari in PHP, accorcia le query, la cache, ecc.
L'ottimizzazione di MySQL è sempre un must, in quanto diminuirà anche la quantità di chiamate databse da parte di PHP, ottenendo così prestazioni migliori. Pertanto, non è possibile che non si possa pensare alle stored procedure, ecc., Se si intende aumentare le prestazioni. Ma MySQL di per sé non sarebbe sufficiente se il tuo codice PHP non fosse ben fatto (molte chiamate di database non necessarie), ecco perché penso che PHP debba essere ben codificato, tenendo presente il processo di hole mentre lo si sviluppa, in modo che le cose non necessarie non si intromette. Cache per esempio, in "duetto" con MySQL corretto, è un grande stimolo alle prestazioni.
puoi sostenere con esperienza personale e/o dati statistici che rispondono in modo specifico alla questione della scalabilità? –
Nella mia esperienza, dovresti inserire la logica di business nel codice PHP piuttosto che spostarlo nel database. Supponendo che il tuo database sia su un server separato, non vuoi che il tuo database sia occupato nel calcolo delle formule quando le richieste arrivano.
Tieni il tuo database veloce per gestire selezioni, inserti e aggiornamenti.
Penso che si disporrà di una scalabilità molto migliore mantenendo il codice di database nel database in cui può essere ottimizzato le prestazioni man mano che il numero di record aumenta. Avrai anche una migliore integrità dei dati che è fondamentale per i dati anche se sono utili. Non si vedono molte dbs relazionali dimensionate con terrabyte con tutto il loro codice nell'applicazione.
Leggere alcuni libri sull'ottimizzazione delle prestazioni del database e quindi decidere se si desidera mettere a rischio i dati della propria azienda sul codice dell'applicazione.
Dopo tanti anni passati a mettere tutto nel PHP, ho iniziato a pensare che avere la logica nel DB rende molte cose più facili, più centrali e più trasparenti. Tuttavia, quando penso alla scalabilità, in qualche modo sembra che il bilanciamento del carico di PHP sia più semplice ed economico e non penso di poter dire lo stesso di MySQL .. puoi far luce su questo per favore? –
Ci sono diversi aspetti da considerare quando si tenta di decidere se posizionare la business logic nel database o nel codice dell'applicazione.
Sarà lo stesso database può accedere da diversi siti web/web applicazioni? Le applicazioni/ dei siti saranno scritte nella stessa lingua o in una lingua diversa?
Se il database verrà utilizzato da un singolo sito e il sito è scritto in una sola lingua, questo diventa un non-problema. In caso contrario, sarà necessario considerare la complessità aggiuntiva delle stored procedure, dei trigger, ecc. Rispetto al tentativo di mantenere la logica di accesso al database ecc. In più basi di codice.
Quali sono i database relazionali in bene generale e che cosa è MySQL bene per specifico? Cosa è meglio PHP ?
Questa considerazione è abbastanza semplice. I database relazionali su tutta la linea e in particolare in qualsiasi variante di SQL stanno andando a fare un ottimo lavoro nell'inserimento, nell'aggiornamento e nell'eliminazione dei dati. Generalmente gestiscono anche le transazioni ATOMIC. Tuttavia, molte varianti di SQL (incluso MySQL) non sono adatte a calcoli complessi, gestione immediata delle date, accesso al file system, ecc.
PHP d'altra parte è molto veloce nel gestire calcoli, date, file system accessi. Prendendo un po 'di tempo puoi persino progettare il tuo codice PHP affinché funzioni in modo tale che i record vengano recuperati una sola volta e quindi archiviati quando necessario.
Cosa ti è più familiare/ comodo con l'utilizzo?
Ovviamente tende ad avere più senso utilizzare lo strumento con cui si è più familiari.
Come ultimo punto considerare che solo perché un trapano può essere utilizzato per tagliare lastre di roccia o perché un martello può essere utilizzato per guidare una vite non significa che dovrebbero essere utilizzati per queste cose. A volte penso che i programmatori facciano più danni potenziali provando a creare strumenti più potenti che fanno tutto invece di creare strumenti più semplici che facciano una cosa veramente, molto bene.
Tutti i punti validi. Ma la parte che devo davvero capire è se avere la possibilità di applicare la logica di biz a livello di DB fosse una cattiva idea, perché dovremmo vedere così tanti DBA molto pagati e molto ricercati nel mondo? –
MySQL utilizza le tecniche avanzate di DB, è semplice e veloce. PHP, essendo un linguaggio dinamico, rende l'elaborazione dei dati molto facile. Pertanto, di solito ha senso usare PHP.
"MySQL fa schifo usando tecniche avanzate di DB" ... questa è una dichiarazione audace, puoi fornire alcuni dati statistici o esempi? ... anche quando dici "di solito ha senso usare PHP" ... quindi puoi dirmi quando è logico NON usare PHP? –
Cosa intendi con "tecniche avanzate di DB"? Quali tecniche avanzate di database MySQL non fornisce? –
mio POV, anche non avendo molta esperienza nello sviluppo di applicazioni di grandi dimensioni è quello di scrivere la logica di business nel DB per alcuni motivi:
1 - manutenibilità, penso che i linguaggi deprecati funzioni e modifiche molte altre cose in breve periodo di tempo, quindi se PHP cambia versione, dovrai adattare il tuo codice alla nuova versione
2 - I DB tendono ad essere più stabili nella lingua, quindi quando esce una nuova versione di un RDBMS, di solito non lo fa t cambia molte cose nel modo in cui scrivi le tue query o SP, o addirittura non cambia. La scrittura della logica in DB ridurrà l'adattamento del codice a causa di una nuova versione DB
3 - Un RDBMS è più probabile che sia vivo per un lungo periodo piuttosto che un linguaggio di programmazione. Inoltre, poiché i dati sono fondamentali, gli sviluppatori RDBMS sono preoccupati di una migrazione automatica di tutti i tuoi dati alla nuova versione di RDBMS, inclusi i tuoi SP. Quando il clipper è morto, non c'erano modi per migrare i sistemi in un nuovo linguaggio di programmazione, dovevano essere completamente riscritti.
4 - Se si pensa che un giorno cambi completamente la lingua per cui si scrive l'applicazione per qualche motivo (la morte della lingua, ad esempio), l'unica cosa da riscrivere sarà la presentazione e le chiamate SP, non la logica aziendale.
Mi piacerebbe sapere da altre persone qui se ciò che ho indicato ha senso, e se no, perché. Sono nella stessa situazione di Sabeen Malik, sto pensando di iniziare il mio primo grande progetto e mi sto occupando degli SP a causa di ciò che ho scritto. Quindi è il momento di correggere il mio POV se non è così corretto.
Puoi quantificare il tasso di richiesta a cui stai pensando? –
Diciamo 100.000 pagine viste al giorno –