Quando non utilizzare ORM e preferire le stored procedure?

13

Sto usando PetaPoco micro-ORM. È davvero molto facile e sicuro lavorare con i database usando gli strumenti ORM, ma l'unica cosa che odio è il codice extra. In passato inserivo la maggior parte del codice nel database stesso e utilizzavo tutte le funzionalità RDBMS come Stored procedure, trigger, ecc., Che è stato creato per gestire meglio.

Voglio sapere quando non utilizzare ORM su Stored procedure / trigger e viceversa.

orm rdbms stored-procedures

— RPK
fonte

6

Personalmente il mio problema con i trigger (in particolare, non si applica alle procedure memorizzate) è che provano a "indovinare" quale "azione aziendale" è avvenuta da come vengono manipolati i dati sul DB. Se modifichi la colonna PREZZO in una tabella "ARTICOLI", non sai davvero perché . L'utente sta semplicemente correggendo un valore errato? È un mark-down? È un'offerta speciale che dura solo un giorno? I trigger devono indovinare tutto ciò.

— Joachim Sauer

16

Gli ORM (mappatura relazionale ad oggetti) non si escludono a vicenda con le Stored Procedure. La maggior parte degli ORM può utilizzare stored procedure. La maggior parte degli ORM genera Stored procedure se lo desideri. Quindi il problema non è né o.

Gli ORM possono generare SQL inaccettabili (in termini di prestazioni) e a volte potresti voler sovrascrivere tale SQL con SQL creato a mano. Uno dei modi per raggiungere questo obiettivo è utilizzare SP (stored procedure).

In DotNet, non utilizzare le procedure memorizzate se:

Se non si ha familiarità con le procedure memorizzate (non nel proprio caso, ma incluse per completezza).
Se non vuoi introdurre uno strato di complessità e versienza al tuo progetto.
Si sta creando un'applicazione che dovrebbe funzionare con database diversi o che dovrebbe essere replicata su più server di database (quest'ultima limitazione potrebbe applicarsi solo per alcuni database).

Si noti che i trigger non devono essere confrontati con gli ORM. I trigger eseguono funzioni che è meglio non essere nel codice dell'applicazione (come la registrazione o la sincronizzazione dei dati tra database).

Alcune persone preferiscono l'uso di Stored Procedure su SQL nel codice per diversi motivi come la sicurezza (ad esempio per impedire l'iniezione di SQL) e per la loro velocità dichiarata. Tuttavia, questo è piuttosto discutibile e necessita di discussioni dettagliate.

Se il tuo ORM non è in grado di generare Stored procedure e devi scrivere un sistema di grandi dimensioni, devi ponderare la codifica manuale aggiuntiva in base al tuo caso.

— Nessuna possibilità
fonte

2

Ritengo che l'argomento di sicurezza non sia correlato all'iniezione SQL, ma piuttosto alle autorizzazioni (ovvero è per lo più semplice gestire le autorizzazioni per una specifica procedura memorizzata per gli utenti che hanno accesso al database, ma gestendo tali autorizzazioni su tabelle, colonne e le file sono più difficili o impossibili). Tuttavia, l'argomento della sicurezza rimane discutibile.

— Arseni Mourzenko,

@MainMa, grazie per il tuo commento. La mia comprensione è che utilizzando SP, si potrebbe ridurre il rischio di iniezione SQL mediante l'uso di una procedura memorizzata parametrizzata con parametri incorporati come suggerisce questo articolo: palpapers.plynt.com/issues/2006Jun/injection-stored-procedures

— NoChance

2

Le procedure memorizzate non hanno praticamente alcun impatto sulla vulnerabilità agli attacchi di iniezione sql. I vecchi miti muoiono duramente.

— Rig

@Rig 1, grazie per il tuo commento, vorrei saperne di più su cosa ne pensi. La mia comprensione deriva da questo testo (almeno): "È possibile contrastare gli attacchi di iniezione di SQL Server utilizzando procedure memorizzate e comandi parametrizzati, evitando SQL dinamici e limitando le autorizzazioni per tutti gli utenti." che appare in msdn.microsoft.com/en-us/library/bb669057.aspx

— NoChance

@EmmadKareem sql con parametri è un grande passo per renderlo sicuro. Penso che questo ragazzo faccia un caso ragionevole palpapers.plynt.com/issues/2006Jun/injection-stored-procedures . Una ricerca su di esso "Stored procedure SQL Injection" genererà molti hit. È sempre utile disinfettare i tuoi input e molte piattaforme forniscono un modo integrato per farlo ragionevolmente bene.

— Rig

13

Gli ORM spesso presuppongono l'esistenza del database per servire l'ORM. Ma di solito esiste il database per servire l'azienda, che potrebbe colpire centinaia e centinaia di app scritte in più lingue.

Ma è solo un caso di "ORM vs. Stored procedure" se si utilizza un ORM che non può chiamare una procedura memorizzata. Altrimenti, si tratta di decidere dove codificare la logica aziendale.

Ovunque codifichi la logica aziendale, il suo compito è assicurarsi che il database passi da uno stato coerente a un altro stato coerente indipendentemente dall'applicazione che esegue la modifica . Quindi hai davvero solo due scelte pratiche: codificalo una volta nel database o codificalo una volta in un livello di accesso ai dati "impenetrabile".

Fai attenzione all'interfaccia della riga di comando di dbms se usi un DAL "impenetrabile".

— Mike Sherrill 'Cat Recall'
fonte

4

Ho incontrato più di un caso in cui i vecchi SP e trigger dovevano essere usati con nuove app a causa di app legacy esistenti. Il vantaggio è che questa logica aziendale deve essere mantenuta in un solo posto.

— jfrankcarr,

Non sto sicuramente negando che sia stato utilizzato "un database per servirli tutti", ma è per lo più un ricordo del passato, in particolare perché la manutenzione diventa un vero inferno, soprattutto quando più applicazioni devono mantenere il proprio versioning dei proc memorizzati. Avere il database esistente per servire l'applicazione che lo possiede è un approccio molto più moderno in quanto applica un accoppiamento più lento tra applicazioni e servizi.

— Flater,

-1

Query semplice -> ORM

Query complessa -> Stored procedure

— Notte oscura
fonte

3

Da dove parte un complesso si separa da una semplice query,

— Indipendente

-2

Il trigger deve essere utilizzato come invariante del record o consistere in regole aziendali vitali, IMHO.

I problemi degli orm:

È necessario impostare le autorizzazioni per le tabelle, non per "Azione" (intendo SP)
Per modificare la logica della soluzione è necessario modificare il codice all'interno dell'app e quindi ridistribuirlo sulla rete per i client

— Yuriy Vikulov
fonte

-5

Disaccordo. La query ORM è più semplice solo se conosci ORM meglio di quanto conosci SQL. L'ORM genera molto più codice, molto più difficile mantenere l'IMO. Le uniche persone che beneficiano di ORM sono gli azionisti della società che vende l'ORM (ad es. Microsoft).

— fantasma
fonte

1

un vero peccato che l'opinione espressa in questa risposta non sia supportata né dai riferimenti né dall'esperienza. Di conseguenza, sarà inutile per un lettore che potrebbe inciampare in un reclamo "inverso" come le procedure memorizzate avvantaggiano solo i fornitori di DB . Fa capire perché la guida in Domande reali hanno risposte afferma: "le domande reali hanno risposte , non elementi o idee o opinioni ... "

— moscerino