Ci sono dei vantaggi nell'usare un generatore di query, piuttosto che usare SQL raw?
per es.
$q->select('*')
->from('posts')
->innerJoin('terms', 'post_id')
->where(...)
vs
SELECT * FROM posts WHERE ...
Vedo che molti framework usano questo tipo di livelli di astrazione, ma non riesco a capire i benefici.
L'astrazione di scrivere lo SQL tramite un framework bene, abstract.
Scrivere SQL a mano non è poi così male da solo, ma inizi a generare problemi con l'escape e l'igienizzazione e questo si trasforma in un disastro. Un livello di astrazione può occuparsi di tutto ciò dietro le quinte, consentendo al tuo codice di essere pulito e privo di molte chiamate di mysql_real_escape_string() o simili.
Inoltre, ciò comporta la possibilità di contabilizzare diversi dialetti di SQL. Non tutti i database sono costruiti allo stesso modo e potrebbero esserci variazioni nelle parole chiave o nella sintassi di una determinata funzionalità. L'utilizzo di un livello di astrazione consente di generare dinamicamente la sintassi corretta della variante.
Sebbene un livello di astrazione possa introdurre un impatto sulle prestazioni, è generalmente trascurabile rispetto alla pulizia e alla robustezza del codice che ricevi in cambio.
I costruttori di query sono un mio odio per gli animali domestici, tanto che ho scritto il mio framework (Apeel) per evitare di usarli!
Se usi PDO (che consiglio vivamente di fare), allora santing l'input viene gestito per te.
Come ha detto qualcun altro, anche se facilitano il passaggio da un database all'altro tendono a supportare la funzionalità di "minimo comune denominatore" e non supporteranno o avranno prestazioni peggiori per funzionalità più avanzate.
Sto sviluppando sistemi con database dal 1986 circa e in tutto questo tempo ho incontrato raramente un'azienda che modifica effettivamente il database che usano diverso da quando avevano bisogno di prestazioni migliori. Se si stanno modificando i database per ottenere prestazioni migliori, è molto più sensato spendere il tempo a mano, ottimizzando le query per ottenere il meglio dal nuovo database anziché prendere il colpo di un generatore di query per semplicità.
Il tempo speso per fare i conti con le qwirks di un generatore di query (quindi riapprendere quando si passa a uno migliore) sarebbe speso molto più produttivamente imparando come ottimizzare il tuo SQL.
In ogni caso, ecco perché NON usarne uno, alcuni li adorano però.
In teoria? Sì. Glenn Nelson ha sottolineato come ti aiuteranno spesso. (Se è un buon generatore di query).
In pratica? Non sempre è all'altezza della teoria e potrebbe effettivamente causare problemi. Supponiamo che tu stia utilizzando un generatore di query contro alcuni DBMS popolari e che tutto sia peachy. Quindi un cliente ti chiede di colpire il loro DBMS che ha qualche stranezza che il tuo generatore di query scelto non è in grado di gestire. (Ho riscontrato questo problema quando ho dovuto lavorare con una versione precedente di Pervasive.)
MA! Quello che dovresti assolutamente fare è separare il Data Access Layer e assicurarti di poterlo sostituire con uno nuovo se necessario. In questo modo è possibile creare un interessante generatore di query con tutte le funzionalità, ma se è necessario inserirne uno nuovo che utilizza lo strano pseudo-sql per il DB in questione.
Penso che il vantaggio pratico e pratico del generatore di query - sia il riutilizzo del codice e la capacità di seguire il principio di DRY.
Con il generatore di query puoi inserire parti di SQL in metodi. E quindi utilizzare questi metodi per comporre SQL complesso. Un esempio potrebbe essere ad es. clausola JOIN riutilizzabile:
function joinTaskWithClient($queryBuilder) {
$queryBuilder->join('task', 'contract', 'task.contract_id = contract.id')
->join('contract', 'client', 'contract.client_id = client.id');
}
Quindi l'utilizzo sarebbe:
$queryBuilder->select('client.name')
->from('client')
->where('task.id=:task')->setParameter('task', 42);
joinTaskWithClient($queryBuilder);
Come si può notare - con il generatore di query è possibile aggiungere parti di SQL in qualsiasi ordine (ad esempio, una parte JOIN dopo WHERE) in contrasto con il caso in cui si raccoglie manualmente la stringa SQL. Inoltre, puoi leggere il modello di builder per vedere i suoi intenti e benefici.
Sono d'accordo riguardo la fuga e l'igienizzazione, ma questo potrebbe essere ottenuto anche con il generatore di query. Per quanto riguarda il tipo di DB / l'astrazione dialettale - questo è un vantaggio piuttosto teorico e discutibile, quasi mai utilizzato nella pratica.
fornirò una risposta basata sul file readme di un mio builder SQL personalizzato ( Dialect )
(testo in chiaro segue, rimossi riferimenti specifici della libreria)
Requisiti
Caratteristiche
Penso che le caratteristiche e i requisiti precedenti descrivano i motivi per cui si userebbe un builder di astrazione SQL
La maggior parte delle funzionalità di cui sopra sono supportate dalla maggior parte dei builder SQL (anche se non penso che tutti i listati siano supportati, per quanto ne so)
Esempi di casi d'uso:
Finalmente, un esempio di un caso d'uso che avevo. Stavo costruendo un'applicazione in cui lo schema DB sottostante (wordpress) non era adatto per il tipo di query di dati che dovevano essere fatte, più alcune delle tabelle WP (ad esempio i post) dovevano essere utilizzate (quindi avere tabelle completamente nuove per tutti i dati dell'applicazione non era un'opzione).
In tal caso, essere in grado di creare un'applicazione simile a MVC in cui il modello potrebbe essere interrogato da condizioni personalizzate / dinamiche, rende la query codifica hard quasi un incubo. Immagina di dover supportare l'interrogazione di un massimo di 2-3 tabelle con join e di filtrare le condizioni per vedere quale tabella aggiungere a cosa e prendersi cura anche degli alias richiesti e così via.
Chiaramente questo era un caso d'uso di astrazione della query e, ancora di più, aveva bisogno (o almeno di grande beneficio) di avere una capacità di definire viste morbide personalizzate (un conglomerato di tabelle unite come se erano un tavolo personalizzato adatto al modello). Quindi è stato molto più semplice, pulito, modulare e flessibile. In un altro aspetto, l'applicazione (codice) ha anche utilizzato il livello di astrazione della query come strumento (schema db) . Come alcuni dicono, era a prova di futuro .
Se, domani, le persone decideranno di aver bisogno di alcune opzioni o dati extra, è molto facile aggiungerli al modello in un paio di righe e lavorare bene. Addizionalmente, se, al più tardi, le persone decidono che non vogliono più usare wordpress (dato che l'applicazione è liberamente accoppiata a wordpress come un plugin), è anche relativamente facile da cambiare ( solo la definizione di ) i modelli in un paio di righe di codice per adattarsi al nuovo schema.
Vedi cosa intendo?
Molto spesso, alcuni degli argomenti per queste query sono in effetti alcuni valori piuttosto che costanti. Ora, molti di questi sono stati essenzialmente derivati dai post dei moduli utente. E quindi ci sono molte possibilità per gli attacchi di SQL injection. Pertanto, la formazione di query inerente richiede una convalida completa.
Ora, questo non vuol dire che non ci si possa fidare degli sviluppatori, ma la formazione della query potrebbe essere semplice, ma ripetere tutti i possibili controlli di validazione in tutto il mondo potrebbe semplicemente significare che potresti perdere qualcuno a caso o modificare la query ma non modificare interrogare ma non aggiornare il controllo di convalida. Alcuni principianti potrebbero anche sapere tutti i pericoli di perdere questo. Quindi l'astrazione del generatore di query è abbastanza essenziale.
Ero abituato a pensare che i builder di query fossero app della GUI che permettevano di selezionare tabelle e creare graficamente i join durante la generazione di SQL sotto il cofano, ma ora capisco che chiami anche i builder di query le API che forniscono un modo per non dover creare pura query SQL, in modo da astrarre te stesso dalle potenziali differenze nei sapori SQL.
L'uso di tali creatori di query è buono , ma tendo a pensare che le persone che si affidano pesantemente a loro tendono a non chiedere agli amministratori di database: "hey, questa è una query che uso molto, per favore crea un guarda da esso ".
Non fraintendermi.
Penso che dovresti scrivere query su viste e non su tabelle. Non per sicurezza o filtraggio, che sono buone ragioni, ma per lo stesso motivo si dovrebbe codificare contro interfacce e non contro classi concrete: disaccoppiamento. Le viste sono come "contratti", allo stesso modo le interfacce sono "contratti" in OOP. Puoi modificare le tabelle sottostanti, ma finché imponi alle visualizzazioni di mostrare lo stesso "contratto" ai programmatori, il codice non dovrebbe interrompersi.
Ancora una volta, non fraintendermi, puoi usare i creatori di query per interrogare le viste, ma molte visualizzazioni si presentano come un processo di creazione che è il prodotto di dover scrivere query e chiedere al tuo DBA: "uomo, crea questo , per favore ".
Mi sbaglio nel pensare che non scrivendo query non riesci a rilevare la necessità di creare determinate visualizzazioni?
Un'altra cosa che mi riguarda sono i programmatori inesperti che non controllano SQL, uno dei pezzi di tecnologia più belli creati dall'uomo, non dovendo farlo.
Leggi altre domande sui tag sql php frameworks