Sto scrivendo un'applicazione che userà molte tabelle e mi è stato detto che non devo usare le stored procedure in questo progetto perché sarà troppo lento.
È stato suggerito di usare TSQL. Ho usato solo le stored procedure fino ad ora.
L'uso di TSQL è diverso? È questa la strada da percorrere per un accesso ai dati più veloce o ci sono altri metodi?
Puoi accedere ai dati nei seguenti modi (supponendo che tu stia usando .NET) - tra gli altri:
(1) utilizzando ADO.NET (e LINQ)
(2) utilizzando ODBC (non consigliato se è possibile utilizzare altre opzioni)
(3) utilizzando T-SQL tramite ADO.NET
(3A) che utilizza T-SQL tramite LINQ
(4) utilizzando SQL Server CLR (codice C # sul lato server)
Il dibattito tra l'uso di (1) e (3) è un dibattito in corso, tuttavia, se non si hanno intenzioni di cambiare il database in un altro, è abbastanza comune programmare il livello del database in T-SQL. T-SQL è principalmente utilizzato per eseguire operazioni di base di creazione, lettura, aggiornamento ed eliminazione e l'elaborazione di trigger. A differenza del semplice ADO.NET, T-SQL può essere più sicuro poiché mantiene il codice SQL libero.
La maggior parte degli strumenti ORM genera codice per (1) o (4). Quindi il tuo strumento potrebbe influenzare la tua decisione.
Se hai una logica complessa e un calcolo intensivo o se richiedi diverse chiamate al database prima che la tua unità di lavoro sia completata, puoi usare (4).
Potresti essere interessato a saperne di più al seguente link: link
Devo dire che sono un po 'perplesso dalla domanda iniziale. Presumibilmente quando hai scritto le stored procedure hai usato T-SQL? Inoltre non sono convinto che le stored procedure saranno in realtà particolarmente lente, o più lente di altri metodi di accesso ai dati. Lavorare con stored procedure ha i suoi problemi, ma nella mia esperienza la velocità non è normalmente una di queste.
Se il tuo cliente non vuole usare stored procedure, probabilmente non c'è nulla che tu possa fare al riguardo. Alla fine della giornata si tratta di mantenere felici gli scommettitori.
La velocità probabilmente non dovrebbe essere la tua unica considerazione. In termini di produttività e manutenibilità T-SQL può avere problemi perché non è un linguaggio di programmazione completo e generico. Non supporta la programmazione orientata agli oggetti o funzionale e persino il passaggio dei dati da una stored procedure a un'altra può risultare un po 'divertente in alcuni casi. Ci sono molte meno librerie di codici disponibili. Il supporto per il debug non è buono. Oltre ad alcune delle istruzioni SQL non elaborate, sarà probabilmente molto difficile portarlo. L'unico ambiente in cui T-SQL può essere eseguito è quello che devi pagare (con l'eccezione di Express Edition).
Ora è possibile utilizzare il CLR di SQL Server per aggirare alcuni di questi problemi, ma sono state imposte molte limitazioni affinché Microsoft possa integrarlo con SQL Server e garantire che il codice scritto in modo errato nel CLR non trascini l'intero contenuto banca dati.
D'altro canto, se nel database è presente una quantità sufficiente di logica aziendale, non è necessario preoccuparsi del mapping relazionale tra oggetti e probabilmente verrà eseguito più velocemente di un livello di accesso ai dati orientato agli oggetti codificato a mano.
La maggior parte delle persone decide di mettere la maggior parte o tutta la propria logica di business al di fuori del database, ma è possibile inserirne la maggior parte in una sola.
Per gli sviluppatori di stack Microsoft, Entity Framework con Asp.net-MVC funziona molto bene. Fornisce una "codifica-connessione" tra il sistema di database TSQL e il codice della pagina web. È divertente svilupparsi, perché funziona 'out-of-the-box', ma si possono aggiungere diversi 'campane e fischietti'. Per i progetti aziendali su larga scala, tuttavia, potrebbe essere necessaria la personalizzazione per evitare di essere troppo lenti - a volte è necessario trovare un'altra alternativa interamente. Per spostarli in produzione, in genere il team operativo deve aprire i firewall e così via.