Procedure memorizzate o ORM nel web?

Il problema con stored procedure nel tuo caso sono i database multipli.

Come fai notare. se si deve modificare un sproc, sarà necessario distribuire tale modifica in ogni database. Dove, come se si mantenga l'SQL nel codice, si può ottenere solo una volta distribuito il codice.

Quindi da un angolo di manutenzione SQL nel codice sarà più facile

Gli SProc aggiungono un livello di astrazione al datalayer, il che aiuta se si dispone di un team di database separato. Ma non è insolito saltare questi SProc in questi giorni.

I database separati per società hanno il vantaggio di aggiungere ulteriore garanzia che i dati sono completamente separati.

Tuttavia, dovresti prendere in considerazione la possibilità di progettare il tuo codice per lavorare con più società e più anni aziendali in un unico database. Ciò contribuirà a ridimensionare e ridurre i costi di manutenzione.

Le procedure memorizzate rispetto a ORM non sono una decisione chiara e tagliata. Otterrai le risposte su entrambi i lati della domanda.

Le stored procedure avranno sempre un vantaggio rispetto a ORM in quanto possono essere precompilate utilizzando statistiche e informazioni sugli indici che il motore di database può estrarre dalle tabelle di dati. Quindi funzioneranno sempre meglio. Ma a seconda di ciò che stai facendo, potrebbe non avere molta importanza, ad esempio se una chiamata impiega 0,3 secondi contro 0,5 secondi.

Onestamente, la parte peggiore del tuo progetto è il database multiplo. Dovresti provare a spostarti verso multitenancy in un unico database, se possibile. Renderà la tua vita molto più facile. Se sei preoccupato che cresca troppo, puoi consultare il clustering , < a href="https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server"> gruppi di disponibilità e viste partizionate distribuite .

Se insisti a mantenere più database, dovresti esaminare replica dello schema , che renderà l'implementazione delle stored procedure e dei trigger più facile e meno incline all'errore umano.

Interessante domanda e d'accordo con John Wu non c'è una risposta "giusta" chiara, dipende dalle priorità e dall'abilità generale della squadra. Mantenere il livello di abilità delle squadre in C # e RDBMS ha molto valore secondo me. Ho visto molti orrori di codice causati da sviluppatori meno esperti che non capiscono come funzionano i database, quindi mantenere i livelli di abilità all'altezza li attenua.

La scelta di stored procedure ti lega piuttosto strettamente a un RDBMS. Non è impossibile supportare più di una (Vedi SAP) ma non è desiderabile. Se hai più clienti che hanno un motivo specifico per volere che il tuo sistema esegua sul loro RDBMS, probabilmente è meglio astrarre il database che significa ORM.

L'uso di un ORM semplifica l'accesso al database, rimuove una percentuale della necessità di utilizzare l'SQL diretto - ma NON al 100%, Non posso sottolineare abbastanza questo punto. Se stai scrivendo applicazioni che accedono a un RDBMS non è possibile ignorare completamente SQL codificato a mano e fare tutto tramite l'ORM a meno che l'app non sia così banale da non giustificare l'utilizzo di un RDBMS o sei disposto a sopportare orrende prestazione. ORM astrae il database a costo di non capire il modo in cui i dati sono archiviati nel database e quali sono le implicazioni del design del database. Per la maggior parte dei sistemi aziendali interni è improbabile che il "vantaggio" di poter passare da un RDBMS a un altro facilmente sia utile - i grandi corps non fanno cadere Oracle per capriccio di andare su MySQL se scelgono quel percorso che il progetto sarà immenso e il costo di riscrivere un po 'di SQL e alcuni Procored Stored saranno sminuiti dal resto dei costi. Se sei una piccola azienda in cui ottenere la vendita potrebbe dipendere dalla tua capacità di supportare (inserire qui gli RDBMS obsoleti) e quella da te sviluppata per un ORM potrebbe essere una valida opzione.