Come ottimizzare un'attività complessa con più chiamate DB

2

Ho lavorato a un'applicazione di gestione delle vendite multilivello sviluppata con WPF e parzialmente refactored con EF6 (lunga storia). L'applicazione ha alcune attività molto complesse che richiedono più chiamate al database con evidenti problemi di prestazioni. Ad esempio, per emettere un ordine cliente, l'applicazione esegue un'attività che richiede la lettura, l'inserimento e l'aggiornamento di almeno una dozzina di tabelle DB o più. Ci sono evidenti problemi architettonici. Un refactoring è fuori questione perché richiederebbe riscrivere l'intera applicazione. Ma non potevo smettere di pensare a come avrei affrontato un'applicazione che richiedeva la scrittura di dati su così tanti tavoli se avessi avuto la possibilità di scriverla da zero.

Quindi, se dovessi sviluppare un'applicazione con tali requisiti e dovessi mantenere l'EF6 come tecnologia sottostante, la mia domanda è: come progetteresti le attività che richiedevano più chiamate DB? Ho pensato ad alcune opzioni:

  • scrivendo i dati su 1 o 2 tabelle principali, scrivendo il resto dei dati correlati su una tabella di supporto e abilitando i trigger sul DB che distribuirebbero i dati dalla tabella di supporto alle tabelle di destinazione.

  • chiamando una singola stored procedure che si occuperà di scrivere tutti i dati nelle tabelle di destinazione (ma non sono un fan della scrittura di business logic nel DB)

  • utilizzando le chiamate asincrone dove possibile, ma potrebbe risultare complicato per mantenere sincronizzati i contenuti.

  • suddividere l'attività in modo che i dati correlati vengano scritti in un batch automatizzato in un secondo momento. Questa opzione mi sembra la più soggetta a errori.

Qualche pensiero?

    
posta Marco 20.06.2018 - 12:39
fonte

1 risposta

1

Hai alcuni dati e alcune logiche di business che utilizzano quei dati. Hai un problema di prestazioni spostando i dati nella logica. La cosa più semplice sarebbe spostare la logica sui dati implementandola nelle stored procedure nel database. Le altre opzioni aggiungerebbero ulteriore logica / complessità che non affronta direttamente il problema aziendale, ma risolve i problemi tecnici introdotti scegliendo questa architettura.

    
risposta data 20.06.2018 - 16:11
fonte

Leggi altre domande sui tag