SQL Server 2008 – Entier non signé de Types de Données

Je suis à l'aide de SQL SERVER 2008, j'ai un nombre de type INT, SMALLINT champs de mes tables, Et je sais qu'ils seront tous à 0 ou supérieure à 0 c'est à dire que je peux les prendre non signé.

Est-il un moyen simple de créer/utiliser Unsigned types de données OU devrai-je Créer type->Faire de la Règle->Utiliser le Type Créé; comme spécifié dans l'article suivant?

http://www.julian-kuiters.id.au/article.php/sqlserver2005-unsigned-integer

Si c'est la seule façon d'utiliser non signé dans SQL, est-il un inconvénient/inconvénient de l'utilisation d'?

Si la raison en est que vous voulez juste pour s'assurer que la valeur est supérieure à égale à zéro, alors vous pouvez utiliser un simple CHECK contrainte sur la colonne.
En prenant non signé, nous pouvons utiliser la mémoire/stockage dans une meilleure façon. Et la raison n'est PAS de s'assurer que la valeur est supérieure à 0 OU pas. C'est purement pour le bien de sauver la mémoire.
On dirait que vous essayez d'optimiser quelque chose que vous ne devriez pas. Laissez le SGBD gérer sa mémoire, c'est très bien.
Je vais avoir lakhs de lignes dans ma table, et il y a une colonne dont la valeur doit être dans la gamme de 50000-60000, n'est-ce pas une bonne idée de prendre comme smallint unsigned. Aussi, j'ai un autre cas où Unsigned Int peut être utilisé à la place de type Bigint.
Il suffit d'utiliser une integer et ajouter un CHECK contrainte ou de déclencheurs pour vérifier les valeurs.

OriginalL'auteur user899055 | 2011-09-01

11

Le principal (et plutôt critique) inconvénient est qu'il me semble que le lien que vous fournissez n'est pas réellement ce que vous pensez que cela fonctionne.

Il se contente tout simplement d'un nouveau type entier qui ne peut être positif, il n'est pas de vous fournir de l'économie de l'espace qui serait autrement lors de l'utilisation d'un unsigned champ (ce qui semble être votre objectif principal). c'est-à-dire que la valeur max de leur unsignedSmallint serait la même que la valeur max pour smallint, vous serait donc encore être en train de perdre ceux des Bits supplémentaires (mais plus que vous ne pouvez pas insérer des valeurs négatives).

C'est-à-dire que leur unsignedInt ne permettrait pas aux valeurs supérieures à 2^31-1.

Je comprends et j'apprécie que 100 millions de lignes les économies réalisées à l'aide d'un int32 vs int64 sur une seule colonne est d'environ 380 MO. Peut-être la meilleure façon pour vous de le faire est de gérer cela est de compenser votre valeur stockée après l'avoir lu, idéalement au sein d'un point de vue et ce n'est que de lire à partir de ce point de vue, et puis quand on fait un insert ajouter -2^31 de la valeur.. Mais le problème est alors que l'analyse syntaxique pour int32 se produit avant de l'insérer de façon à INSTEAD OF déclencheurs ne fonctionne pas.. (je ne sais pas de toute façon de faire un déclencheur INSTEAD OF qui accepte différents types de que de le posséder table)

Au lieu de cela, votre seule option à cet égard consiste à utiliser des procédures stockées pour set la valeur, vous pouvez alors soit utiliser une vue ou d'une procédure stockée pour obtenir la valeur de retour:
```
create table foo
(fooA int)
GO

CREATE VIEW [bar]
AS
SELECT CAST(fooA AS BIGINT) + 2147483647 AS fooA
FROM foo
GO

CREATE PROCEDURE set_foo
    @fooA bigint
AS
BEGIN
    SET NOCOUNT ON;

    -- Insert statements for procedure here
    IF @fooA < 4294967296 AND @fooA >= 0
        INSERT INTO foo VALUES (@fooA - 2147483647)
    --ELSE
        -- throw some message here
END
GO
```
Cela peut être testé à l'aide de:
```
exec set_foo 123
exec set_foo 555
select * FROM bar
select * FROM foo
exec set_foo 0
exec set_foo 2147483648
exec set_foo 4147483648
select * FROM bar
select * FROM foo
```
Vous verrez que les valeurs sont retournées non signé, cependant les valeurs renvoyées sont int64 et pas unsigned32 si votre application a besoin de les traiter comme s'ils étaient encore int64.

Si vous avez un cas, où vous pourrez voir une amélioration significative de faire cela (comme presque chaque colonne de la table est deux fois plus grand que l'autre doit l'être) alors l'effort ci-dessus pourrait être justifié, sinon, je voudrais juste rester avec bigint à la place.

OriginalL'auteur Seph
3

Pour convertir signé smallint un nombre non signé, essayez ceci:
```
CAST(yourSignedSmallInt AS int) & 0xffff
```
Pour convertir signé int un nombre non signé essayer
```
CAST(yourSignedInt AS bigint) & 0xffffffff
```
par exemple, si votre table de champ x est un smallint et que vous souhaitez retourner la unsigned valeur puis essayez
```
SELECT (CAST(x AS int) & 0xffff) FROM ... WHERE ....
```
OriginalL'auteur boston engineer
2

La solution la plus appropriée dépend du problème que vous essayez de résoudre. Si c'est un champ d'identité, et votre objectif est de doubler le nombre de lignes de votre table peut contenir sans stockage de 4 octets supplémentaires à chaque ligne pour utiliser un bigint, puis il suffit de semences au champ à -2,147,483,648 plutôt que 1. Si vous avez besoin de stocker des valeurs supérieures à 2.147 milliards de dollars, puis aller avec un plus grand type de données.

OriginalL'auteur Tim F

Vous devez vous connecter pour publier un commentaire.