Domanda

Ho una pagina web che ho collegato a a procedura memorizzata.In questa origine dati SQL ho un parametro che sto restituendo alla procedura memorizzata di tipo int.

ASP.NET sembra voler impostare per impostazione predefinita int32, ma il numero non supererà 6.È corretto sovrascrivere l'impostazione predefinita di ASP.NET e inserirne 16 o si verificherà un conflitto da qualche parte lungo la strada?

specifica:il campo del database ha una lunghezza pari a 4 e una precisione pari a 10, se ciò fa la differenza nella risposta.

È stato utile?

Soluzione

Se forzi che sia, ad esempio, un byte e il numero è superiore a 255, corri il rischio di un errore di casting (e verrà generata un'eccezione).Tuttavia, se sai che non sarà superiore a 6, non dovrebbe essere un problema.

Se fossi in me, lo userei semplicemente come un normale int, non sono sicuro che risparmierai molto se non qualche byte trasformandolo in un byte.Il rischio che l'eccezione venga generata è troppo alto e si perderebbero tutti i vantaggi riducendola.

Altri suggerimenti

Attenersi a int32.Questo è comunque l'"Integer" di vb e l'INT di SQL.

Non otterrai alcun miglioramento significativo delle prestazioni utilizzando tinyint/byte o short/int16 invece di int/int32.

In effetti, i mal di testa che potresti incontrare in futuro causati da tutto il casting che potresti dover fare per oggetti che si aspettano int32 ti faranno impazzire.

Quando dici che il campo DB ha una lunghezza di 4, significa 4 byte, che equivale a un Int32 (4 byte = 32 bit).Ecco perché la tua colonna viene restituita come int32.

Ce ne sono diversi tipi di dati interi in SQL Server: se sei sicuro che il numero non supererà 6, dovresti dichiarare la colonna nel database come "tinyint", che utilizza un singolo byte e può contenere valori da 0 a 255.Quindi l'origine dati SQL dovrebbe convertirlo in un tipo di dati "byte", che andrà bene per i tuoi scopi.

Clr "byte" == sql "tinyint" (1 byte) clr "short" (o int16) == sql "smallint" (2 byte) clr "int32" == sql "int"

MODIFICARE:solo perché puoi fare qualcosa, non significa che dovresti -- sono d'accordo Michael Haren, il problema dello sviluppo derivante dalla gestione di questi tipi di dati meno comuni supera il piccolo miglioramento delle prestazioni che otterresti, a meno che tu non abbia a che fare con software ad altissime prestazioni (nel qual caso, perché dovresti utilizzare ASP.NET?)

Non stai risparmiando molto se non altro utilizzando un Int16 sul lato ASP.Alla fine deve ancora caricarlo in un registro a 32 bit.

Per tua informazione, CLR associa comunque int a Int32 internamente.

Usa qualunque sia il tuo Server SQL la procedura memorizzata è definita.Se è un int in SQL Server, quindi utilizza Int32 in .NET.smallint in SQL è int16.

In caso contrario, SQL Server eseguirà automaticamente l'upconversion o genererà un errore se è necessario effettuare la downconversion.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top