Come ottimizzare le funzionalità di MySQL quando utilizzato con php

Question

Come ottimizzare le funzionalità di MySQL quando utilizzato con php

#1 da (1 voti)

1

Ho posto questa domanda un po 'indietro su SO ( link ) ma è un argomento ricorrente, quindi ho pensato di chiedere in un modo diverso qui.

Fondamentalmente, siamo bloccati con l'infame combinazione di php e MySQL (per vari motivi) e stiamo cercando di produrre applicazioni che seguano il più possibile le migliori pratiche. Ci accorgiamo ripetutamente che stiamo accoppiando strettamente l'applicazione al database e viceversa, nonostante proviamo ad aderire a SOLID principi.

Uno dei motivi principali è massimizzare le caratteristiche di un database relazionale (come tipi di dati rigorosi, strutture gerarchiche di dati, relazioni, rafforzamento di chiavi esterne, trigger di innesco, ecc.) Ciò significa che parte della logica dell'applicazione si insinua in SQL. Tuttavia, ci sono caratteristiche che offrono altri RDBMS che MySQL non possiede (come il vincolo CHECK in particolare) così, finiamo per usare php per aggirare quelli.

Questo significa che finiamo per usare php per alcune cose che MySQL non fa bene e usiamo MySQL per fare cose che non sono fattibili in PHP.

Quindi, anche se ogni libro di testo incoraggia i programmatori a mantenere le cose unite liberamente, qualcuno ha qualche esempio su come superare i limiti che hai incontrato, o esempi di altre applicazioni che mescolano i due in un modo simile?

programming-practices php mysql

posta boatingcow 01.08.2013 - 11:23

fonte

1 risposta

Leggi altre domande sui tag programming-practices php mysql

Come devo implementare la "messa in coda" dell'approvazione sui miei oggetti? Cercando di creare un editor grafico personalizzato per un modello di dati usando HTML5 e SVG

score 1 · Accepted Answer

In base a questa risposta, è possibile risolvere il problema del COSTANTE CONSEGNA nel livello del database:

link

Tenere presente che le migliori pratiche per un progetto OOP presuppongono che l'applicazione risieda nel codice oop e che il database esista per archiviare i dati da tali oggetti (tramite un fornitore fornito o un livello ORM personalizzato). L'aspettativa è che SQL viene utilizzato principalmente per tradurre oggetti nel database per l'archiviazione permanente, non per la logica dell'applicazione.

Esistono anche le migliori pratiche per le applicazioni SQL. Molte applicazioni sono guidate quasi interamente da un database, con un uso massiccio di stored procedure, trigger, viste e altre funzionalità SQL che sono accoppiate a quel database. In questo tipo di applicazione, il codice php sta principalmente recuperando i dati e gestendo l'input dell'utente, gestendo meno la logica dell'applicazione.

Sia PHP / MySQL sono ampiamente usati per lo sviluppo rapido, ma nessuno dei due sarebbe scambiato per il "capo della classe" nel supporto delle migliori pratiche rispettivamente in OOP / SQL. Questo a volte causa il dolore che descrivi durante l'implementazione delle funzionalità, in quanto devi mescolare i due tipi di applicazioni menzionate sopra (che quindi accoppia l'applicazione insieme). Se questo si traduce in un'applicazione accettabile con risultati di business migliori, potrebbe valerne la pena.

Alla fine, se l'applicazione può funzionare in modo affidabile e implementare le funzionalità richieste nell'ambito del flusso di lavoro corrente, la scelta migliore è salvare la discussione sull'architettura per la prossima applicazione. Se ciò non può essere fatto è un modo ragionevole, quindi considera il tipo di architettura che desideri avere e lavora per migrare l'applicazione.