Bonjour,
Je suis en train d'étudier une refonte d'un système de BDD installé, et
notament j'envisage de remplacer les relations actuelles faites par une
triplette de colonnes CLUSTERED par un id de type IDENTITY :
actuellement j'ai :
trtdate int NOT NULL,
blocid int NOT NULL,
docid int NOT NULL,
...
CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
(
[trtdate],
[blocid],
[docid],
) WITH FILLFACTOR = 90 ON [PRIMARY]
et je voudrais remplacer ça par :
docid int identity (1,1) NOT NULL,
Cette table va être peuplée de au moins 100 000 000, et va probablement
décupler. Les questions que je me pose donc sont :
- quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
(il n'y a rien à ce sujet dans l'aide de MS SQL)
- en terme de performances, est-il plus efficace d'utiliser une triplette
de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
Merci pour vos suggestions ;)
Bonjour,
Je suis en train d'étudier une refonte d'un système de BDD installé, et
notament j'envisage de remplacer les relations actuelles faites par une
triplette de colonnes CLUSTERED par un id de type IDENTITY :
actuellement j'ai :
trtdate int NOT NULL,
blocid int NOT NULL,
docid int NOT NULL,
...
CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
(
[trtdate],
[blocid],
[docid],
) WITH FILLFACTOR = 90 ON [PRIMARY]
et je voudrais remplacer ça par :
docid int identity (1,1) NOT NULL,
Cette table va être peuplée de au moins 100 000 000, et va probablement
décupler. Les questions que je me pose donc sont :
- quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
(il n'y a rien à ce sujet dans l'aide de MS SQL)
- en terme de performances, est-il plus efficace d'utiliser une triplette
de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
Merci pour vos suggestions ;)
Bonjour,
Je suis en train d'étudier une refonte d'un système de BDD installé, et
notament j'envisage de remplacer les relations actuelles faites par une
triplette de colonnes CLUSTERED par un id de type IDENTITY :
actuellement j'ai :
trtdate int NOT NULL,
blocid int NOT NULL,
docid int NOT NULL,
...
CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
(
[trtdate],
[blocid],
[docid],
) WITH FILLFACTOR = 90 ON [PRIMARY]
et je voudrais remplacer ça par :
docid int identity (1,1) NOT NULL,
Cette table va être peuplée de au moins 100 000 000, et va probablement
décupler. Les questions que je me pose donc sont :
- quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
(il n'y a rien à ce sujet dans l'aide de MS SQL)
- en terme de performances, est-il plus efficace d'utiliser une triplette
de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
Merci pour vos suggestions ;)
Bonjour,
Je suis en train d'étudier une refonte d'un système de BDD installé, et
notament j'envisage de remplacer les relations actuelles faites par une
triplette de colonnes CLUSTERED par un id de type IDENTITY :
actuellement j'ai :
trtdate int NOT NULL,
blocid int NOT NULL,
docid int NOT NULL,
...
CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
(
[trtdate],
[blocid],
[docid],
) WITH FILLFACTOR = 90 ON [PRIMARY]
et je voudrais remplacer ça par :
docid int identity (1,1) NOT NULL,
Cette table va être peuplée de au moins 100 000 000, et va probablement
décupler. Les questions que je me pose donc sont :
- quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
(il n'y a rien à ce sujet dans l'aide de MS SQL)
- en terme de performances, est-il plus efficace d'utiliser une triplette
de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
Merci pour vos suggestions ;)
--
Rico
Bonjour,
Je suis en train d'étudier une refonte d'un système de BDD installé, et
notament j'envisage de remplacer les relations actuelles faites par une
triplette de colonnes CLUSTERED par un id de type IDENTITY :
actuellement j'ai :
trtdate int NOT NULL,
blocid int NOT NULL,
docid int NOT NULL,
...
CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
(
[trtdate],
[blocid],
[docid],
) WITH FILLFACTOR = 90 ON [PRIMARY]
et je voudrais remplacer ça par :
docid int identity (1,1) NOT NULL,
Cette table va être peuplée de au moins 100 000 000, et va probablement
décupler. Les questions que je me pose donc sont :
- quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
(il n'y a rien à ce sujet dans l'aide de MS SQL)
- en terme de performances, est-il plus efficace d'utiliser une triplette
de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
Merci pour vos suggestions ;)
--
Rico
Bonjour,
Je suis en train d'étudier une refonte d'un système de BDD installé, et
notament j'envisage de remplacer les relations actuelles faites par une
triplette de colonnes CLUSTERED par un id de type IDENTITY :
actuellement j'ai :
trtdate int NOT NULL,
blocid int NOT NULL,
docid int NOT NULL,
...
CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
(
[trtdate],
[blocid],
[docid],
) WITH FILLFACTOR = 90 ON [PRIMARY]
et je voudrais remplacer ça par :
docid int identity (1,1) NOT NULL,
Cette table va être peuplée de au moins 100 000 000, et va probablement
décupler. Les questions que je me pose donc sont :
- quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
(il n'y a rien à ce sujet dans l'aide de MS SQL)
- en terme de performances, est-il plus efficace d'utiliser une triplette
de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
Merci pour vos suggestions ;)
--
Rico
- en terme de performances, est-il plus efficace d'utiliser une
triplette de clés comme c'est fait actuellement, ou vaut-il mieux une
clé unique ?
la limite de identity est celle du type SQL sous jacent :
int => 4 millards soit 126 ans, à raison d'un insert par seconde
si bigint => 5 849 424 173 siècles dans les mêmes conditions.
Le int sera plus performant en plateforme 32 bits et le bigint sera
plus performant en plateforme 64 bits.
- en terme de performances, est-il plus efficace d'utiliser une
triplette de clés comme c'est fait actuellement, ou vaut-il mieux une
clé unique ?
la limite de identity est celle du type SQL sous jacent :
int => 4 millards soit 126 ans, à raison d'un insert par seconde
si bigint => 5 849 424 173 siècles dans les mêmes conditions.
Le int sera plus performant en plateforme 32 bits et le bigint sera
plus performant en plateforme 64 bits.
- en terme de performances, est-il plus efficace d'utiliser une
triplette de clés comme c'est fait actuellement, ou vaut-il mieux une
clé unique ?
la limite de identity est celle du type SQL sous jacent :
int => 4 millards soit 126 ans, à raison d'un insert par seconde
si bigint => 5 849 424 173 siècles dans les mêmes conditions.
Le int sera plus performant en plateforme 32 bits et le bigint sera
plus performant en plateforme 64 bits.
"SQLpro [MVP]" wrote in
news::- en terme de performances, est-il plus efficace d'utiliser une
triplette de clés comme c'est fait actuellement, ou vaut-il mieux une
clé unique ?
la limite de identity est celle du type SQL sous jacent :
int => 4 millards soit 126 ans, à raison d'un insert par seconde
si bigint => 5 849 424 173 siècles dans les mêmes conditions.
merci pour ces précisions : je me doutais effectivement que identity etait
typée par le type précisé... juste une autre question : que se passe-t-il
lorsqu'on arrive au fatidiques 4 milliards ?
Le int sera plus performant en plateforme 32 bits et le bigint sera
plus performant en plateforme 64 bits.
donc un index IDENTITY sera toujours plus performant qu'une clé CLUSTER ?
"SQLpro [MVP]" <brouardf@club-internet.fr> wrote in
news:O049j4DTGHA.1728@TK2MSFTNGP11.phx.gbl:
- en terme de performances, est-il plus efficace d'utiliser une
triplette de clés comme c'est fait actuellement, ou vaut-il mieux une
clé unique ?
la limite de identity est celle du type SQL sous jacent :
int => 4 millards soit 126 ans, à raison d'un insert par seconde
si bigint => 5 849 424 173 siècles dans les mêmes conditions.
merci pour ces précisions : je me doutais effectivement que identity etait
typée par le type précisé... juste une autre question : que se passe-t-il
lorsqu'on arrive au fatidiques 4 milliards ?
Le int sera plus performant en plateforme 32 bits et le bigint sera
plus performant en plateforme 64 bits.
donc un index IDENTITY sera toujours plus performant qu'une clé CLUSTER ?
"SQLpro [MVP]" wrote in
news::- en terme de performances, est-il plus efficace d'utiliser une
triplette de clés comme c'est fait actuellement, ou vaut-il mieux une
clé unique ?
la limite de identity est celle du type SQL sous jacent :
int => 4 millards soit 126 ans, à raison d'un insert par seconde
si bigint => 5 849 424 173 siècles dans les mêmes conditions.
merci pour ces précisions : je me doutais effectivement que identity etait
typée par le type précisé... juste une autre question : que se passe-t-il
lorsqu'on arrive au fatidiques 4 milliards ?
Le int sera plus performant en plateforme 32 bits et le bigint sera
plus performant en plateforme 64 bits.
donc un index IDENTITY sera toujours plus performant qu'une clé CLUSTER ?
CREATE TABLE T_TEST_IDENTITY_TID
(TID_ID INT IDENTITY,
TID_DATA VARCHAR(16))
SET IDENTITY_INSERT T_TEST_IDENTITY_TID ON
INSERT INTO T_TEST_IDENTITY_TID (TID_ID, TID_DATA) VALUES (2147483647,
'toto')
SET IDENTITY_INSERT T_TEST_IDENTITY_TID OFF
INSERT INTO T_TEST_IDENTITY_TID (TID_DATA) VALUES ('tata')
Serveur : Msg 8115, Niveau 16, État 1, Ligne 1
Dépassement de capacité lors de la conversion de IDENTITY au type de
données int.
Débordement arithmétique.
SELECT * FROM T_TEST_IDENTITY_TID
TID_ID TID_DATA
----------- ----------------
2147483647 toto
mais vous pouvez faire un RESEED (DBCC CHECKIDENT)
donc un index IDENTITY sera toujours plus performant qu'une clé
CLUSTER ?
IDENTITY n'est pas un index, juste un autoinc.
Une PK ou une contrainte UNIQUE générera un index.
CREATE TABLE T_TEST_IDENTITY_TID
(TID_ID INT IDENTITY,
TID_DATA VARCHAR(16))
SET IDENTITY_INSERT T_TEST_IDENTITY_TID ON
INSERT INTO T_TEST_IDENTITY_TID (TID_ID, TID_DATA) VALUES (2147483647,
'toto')
SET IDENTITY_INSERT T_TEST_IDENTITY_TID OFF
INSERT INTO T_TEST_IDENTITY_TID (TID_DATA) VALUES ('tata')
Serveur : Msg 8115, Niveau 16, État 1, Ligne 1
Dépassement de capacité lors de la conversion de IDENTITY au type de
données int.
Débordement arithmétique.
SELECT * FROM T_TEST_IDENTITY_TID
TID_ID TID_DATA
----------- ----------------
2147483647 toto
mais vous pouvez faire un RESEED (DBCC CHECKIDENT)
donc un index IDENTITY sera toujours plus performant qu'une clé
CLUSTER ?
IDENTITY n'est pas un index, juste un autoinc.
Une PK ou une contrainte UNIQUE générera un index.
CREATE TABLE T_TEST_IDENTITY_TID
(TID_ID INT IDENTITY,
TID_DATA VARCHAR(16))
SET IDENTITY_INSERT T_TEST_IDENTITY_TID ON
INSERT INTO T_TEST_IDENTITY_TID (TID_ID, TID_DATA) VALUES (2147483647,
'toto')
SET IDENTITY_INSERT T_TEST_IDENTITY_TID OFF
INSERT INTO T_TEST_IDENTITY_TID (TID_DATA) VALUES ('tata')
Serveur : Msg 8115, Niveau 16, État 1, Ligne 1
Dépassement de capacité lors de la conversion de IDENTITY au type de
données int.
Débordement arithmétique.
SELECT * FROM T_TEST_IDENTITY_TID
TID_ID TID_DATA
----------- ----------------
2147483647 toto
mais vous pouvez faire un RESEED (DBCC CHECKIDENT)
donc un index IDENTITY sera toujours plus performant qu'une clé
CLUSTER ?
IDENTITY n'est pas un index, juste un autoinc.
Une PK ou une contrainte UNIQUE générera un index.
"SQLpro [MVP]" wrote in
news::CREATE TABLE T_TEST_IDENTITY_TID
(TID_ID INT IDENTITY,
TID_DATA VARCHAR(16))
SET IDENTITY_INSERT T_TEST_IDENTITY_TID ON
INSERT INTO T_TEST_IDENTITY_TID (TID_ID, TID_DATA) VALUES (2147483647,
'toto')
SET IDENTITY_INSERT T_TEST_IDENTITY_TID OFF
INSERT INTO T_TEST_IDENTITY_TID (TID_DATA) VALUES ('tata')
Serveur : Msg 8115, Niveau 16, État 1, Ligne 1
Dépassement de capacité lors de la conversion de IDENTITY au type de
données int.
Débordement arithmétique.
SELECT * FROM T_TEST_IDENTITY_TID
TID_ID TID_DATA
----------- ----------------
2147483647 toto
mais vous pouvez faire un RESEED (DBCC CHECKIDENT)
merci ;)donc un index IDENTITY sera toujours plus performant qu'une clé
CLUSTER ?
IDENTITY n'est pas un index, juste un autoinc.
Une PK ou une contrainte UNIQUE générera un index.
oui, j'entends bien mais quelle est la meilleur solution ? un index sur
une clé unique, ou bien un index sur une clé CLUSTER ?
"SQLpro [MVP]" <brouardf@club-internet.fr> wrote in
news:uMu78IaTGHA.5172@TK2MSFTNGP12.phx.gbl:
CREATE TABLE T_TEST_IDENTITY_TID
(TID_ID INT IDENTITY,
TID_DATA VARCHAR(16))
SET IDENTITY_INSERT T_TEST_IDENTITY_TID ON
INSERT INTO T_TEST_IDENTITY_TID (TID_ID, TID_DATA) VALUES (2147483647,
'toto')
SET IDENTITY_INSERT T_TEST_IDENTITY_TID OFF
INSERT INTO T_TEST_IDENTITY_TID (TID_DATA) VALUES ('tata')
Serveur : Msg 8115, Niveau 16, État 1, Ligne 1
Dépassement de capacité lors de la conversion de IDENTITY au type de
données int.
Débordement arithmétique.
SELECT * FROM T_TEST_IDENTITY_TID
TID_ID TID_DATA
----------- ----------------
2147483647 toto
mais vous pouvez faire un RESEED (DBCC CHECKIDENT)
merci ;)
donc un index IDENTITY sera toujours plus performant qu'une clé
CLUSTER ?
IDENTITY n'est pas un index, juste un autoinc.
Une PK ou une contrainte UNIQUE générera un index.
oui, j'entends bien mais quelle est la meilleur solution ? un index sur
une clé unique, ou bien un index sur une clé CLUSTER ?
"SQLpro [MVP]" wrote in
news::CREATE TABLE T_TEST_IDENTITY_TID
(TID_ID INT IDENTITY,
TID_DATA VARCHAR(16))
SET IDENTITY_INSERT T_TEST_IDENTITY_TID ON
INSERT INTO T_TEST_IDENTITY_TID (TID_ID, TID_DATA) VALUES (2147483647,
'toto')
SET IDENTITY_INSERT T_TEST_IDENTITY_TID OFF
INSERT INTO T_TEST_IDENTITY_TID (TID_DATA) VALUES ('tata')
Serveur : Msg 8115, Niveau 16, État 1, Ligne 1
Dépassement de capacité lors de la conversion de IDENTITY au type de
données int.
Débordement arithmétique.
SELECT * FROM T_TEST_IDENTITY_TID
TID_ID TID_DATA
----------- ----------------
2147483647 toto
mais vous pouvez faire un RESEED (DBCC CHECKIDENT)
merci ;)donc un index IDENTITY sera toujours plus performant qu'une clé
CLUSTER ?
IDENTITY n'est pas un index, juste un autoinc.
Une PK ou une contrainte UNIQUE générera un index.
oui, j'entends bien mais quelle est la meilleur solution ? un index sur
une clé unique, ou bien un index sur une clé CLUSTER ?
une clé n'est pas cluster. C'est l'index qui est CLUSTER ou non.
Lorsque vous créez une PK ou une contrainte UNIQUE SQL Server créé un
index sans vous le dire.
Par défaut PK => index cluster, UNIQUE => index non cluster.
Un index cluster est fortement recommandé lorsque toutes les conditions
suivantes sont recueillies :
1) la clef est monocolonne
2) la valeur de la clef ne change JAMAIS
3) la ditribution des valeurs de clef dans le temps est monotone
dans tous les autres cas, considérez un index non cluster.
une clé n'est pas cluster. C'est l'index qui est CLUSTER ou non.
Lorsque vous créez une PK ou une contrainte UNIQUE SQL Server créé un
index sans vous le dire.
Par défaut PK => index cluster, UNIQUE => index non cluster.
Un index cluster est fortement recommandé lorsque toutes les conditions
suivantes sont recueillies :
1) la clef est monocolonne
2) la valeur de la clef ne change JAMAIS
3) la ditribution des valeurs de clef dans le temps est monotone
dans tous les autres cas, considérez un index non cluster.
une clé n'est pas cluster. C'est l'index qui est CLUSTER ou non.
Lorsque vous créez une PK ou une contrainte UNIQUE SQL Server créé un
index sans vous le dire.
Par défaut PK => index cluster, UNIQUE => index non cluster.
Un index cluster est fortement recommandé lorsque toutes les conditions
suivantes sont recueillies :
1) la clef est monocolonne
2) la valeur de la clef ne change JAMAIS
3) la ditribution des valeurs de clef dans le temps est monotone
dans tous les autres cas, considérez un index non cluster.
"SQLpro [MVP]" wrote in news:u1QAOfbTGHA.5108
@TK2MSFTNGP11.phx.gbl:une clé n'est pas cluster. C'est l'index qui est CLUSTER ou non.
Lorsque vous créez une PK ou une contrainte UNIQUE SQL Server créé un
index sans vous le dire.
Par défaut PK => index cluster, UNIQUE => index non cluster.
Un index cluster est fortement recommandé lorsque toutes les conditions
suivantes sont recueillies :
1) la clef est monocolonne
2) la valeur de la clef ne change JAMAIS
3) la ditribution des valeurs de clef dans le temps est monotone
dans tous les autres cas, considérez un index non cluster.
merci pour le cours de sémantique ;)
donc si j'ai bien intégré la leçon, le mieux dans le cas qui me préocupe
serait de créer une colonne int identity avec une contrainte unique
clustered
j'ai bon ?
bien sûr, ce ne sera pas incompatible avec d'autres index additionnels ?
"SQLpro [MVP]" <brouardf@club-internet.fr> wrote in news:u1QAOfbTGHA.5108
@TK2MSFTNGP11.phx.gbl:
une clé n'est pas cluster. C'est l'index qui est CLUSTER ou non.
Lorsque vous créez une PK ou une contrainte UNIQUE SQL Server créé un
index sans vous le dire.
Par défaut PK => index cluster, UNIQUE => index non cluster.
Un index cluster est fortement recommandé lorsque toutes les conditions
suivantes sont recueillies :
1) la clef est monocolonne
2) la valeur de la clef ne change JAMAIS
3) la ditribution des valeurs de clef dans le temps est monotone
dans tous les autres cas, considérez un index non cluster.
merci pour le cours de sémantique ;)
donc si j'ai bien intégré la leçon, le mieux dans le cas qui me préocupe
serait de créer une colonne int identity avec une contrainte unique
clustered
j'ai bon ?
bien sûr, ce ne sera pas incompatible avec d'autres index additionnels ?
"SQLpro [MVP]" wrote in news:u1QAOfbTGHA.5108
@TK2MSFTNGP11.phx.gbl:une clé n'est pas cluster. C'est l'index qui est CLUSTER ou non.
Lorsque vous créez une PK ou une contrainte UNIQUE SQL Server créé un
index sans vous le dire.
Par défaut PK => index cluster, UNIQUE => index non cluster.
Un index cluster est fortement recommandé lorsque toutes les conditions
suivantes sont recueillies :
1) la clef est monocolonne
2) la valeur de la clef ne change JAMAIS
3) la ditribution des valeurs de clef dans le temps est monotone
dans tous les autres cas, considérez un index non cluster.
merci pour le cours de sémantique ;)
donc si j'ai bien intégré la leçon, le mieux dans le cas qui me préocupe
serait de créer une colonne int identity avec une contrainte unique
clustered
j'ai bon ?
bien sûr, ce ne sera pas incompatible avec d'autres index additionnels ?
Bonjour,
la propriété identity s'applique à un type de données
Les types autorisés sont : tinyint, smallint, int, bigint, decimal(p,0), or
numeric(p,0)
Le nb de valeurs autorisées est donc dépendant du type utilisé.
Dans le cas du type int : -2^31 (-2,147,483,648) jusqu'à 2^31 - 1
(2,147,483,647).
Dans votre cas, le type int devrait donc suffire
Dans le cas contraire un bigint peut être utilisé. Il utilise par contre 8
octets au lieu de 4 pour stocker la valeur.
-2^63 (-9,223,372,036,854,775,808) jusqu'à 2^63-1
(9,223,372,036,854,775,807).
J. Berthaud
Winsight
"Eric Belhomme" <{rico}+no/ wrote in message
news:
> Bonjour,
>
> Je suis en train d'étudier une refonte d'un système de BDD installé, et
> notament j'envisage de remplacer les relations actuelles faites par une
> triplette de colonnes CLUSTERED par un id de type IDENTITY :
>
> actuellement j'ai :
>
> trtdate int NOT NULL,
> blocid int NOT NULL,
> docid int NOT NULL,
> ...
> CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
> (
> [trtdate],
> [blocid],
> [docid],
> ) WITH FILLFACTOR = 90 ON [PRIMARY]
>
> et je voudrais remplacer ça par :
>
> docid int identity (1,1) NOT NULL,
>
> Cette table va être peuplée de au moins 100 000 000, et va probablement
> décupler. Les questions que je me pose donc sont :
> - quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
> (il n'y a rien à ce sujet dans l'aide de MS SQL)
> - en terme de performances, est-il plus efficace d'utiliser une triplette
> de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
>
> Merci pour vos suggestions ;)
>
> --
> Rico
Bonjour,
la propriété identity s'applique à un type de données
Les types autorisés sont : tinyint, smallint, int, bigint, decimal(p,0), or
numeric(p,0)
Le nb de valeurs autorisées est donc dépendant du type utilisé.
Dans le cas du type int : -2^31 (-2,147,483,648) jusqu'à 2^31 - 1
(2,147,483,647).
Dans votre cas, le type int devrait donc suffire
Dans le cas contraire un bigint peut être utilisé. Il utilise par contre 8
octets au lieu de 4 pour stocker la valeur.
-2^63 (-9,223,372,036,854,775,808) jusqu'à 2^63-1
(9,223,372,036,854,775,807).
J. Berthaud
Winsight
"Eric Belhomme" <{rico}+no/spam@ricospirit.net> wrote in message
news:Xns978CB1B653D54ericbelhommefreefr@212.27.42.135...
> Bonjour,
>
> Je suis en train d'étudier une refonte d'un système de BDD installé, et
> notament j'envisage de remplacer les relations actuelles faites par une
> triplette de colonnes CLUSTERED par un id de type IDENTITY :
>
> actuellement j'ai :
>
> trtdate int NOT NULL,
> blocid int NOT NULL,
> docid int NOT NULL,
> ...
> CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
> (
> [trtdate],
> [blocid],
> [docid],
> ) WITH FILLFACTOR = 90 ON [PRIMARY]
>
> et je voudrais remplacer ça par :
>
> docid int identity (1,1) NOT NULL,
>
> Cette table va être peuplée de au moins 100 000 000, et va probablement
> décupler. Les questions que je me pose donc sont :
> - quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
> (il n'y a rien à ce sujet dans l'aide de MS SQL)
> - en terme de performances, est-il plus efficace d'utiliser une triplette
> de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
>
> Merci pour vos suggestions ;)
>
> --
> Rico
Bonjour,
la propriété identity s'applique à un type de données
Les types autorisés sont : tinyint, smallint, int, bigint, decimal(p,0), or
numeric(p,0)
Le nb de valeurs autorisées est donc dépendant du type utilisé.
Dans le cas du type int : -2^31 (-2,147,483,648) jusqu'à 2^31 - 1
(2,147,483,647).
Dans votre cas, le type int devrait donc suffire
Dans le cas contraire un bigint peut être utilisé. Il utilise par contre 8
octets au lieu de 4 pour stocker la valeur.
-2^63 (-9,223,372,036,854,775,808) jusqu'à 2^63-1
(9,223,372,036,854,775,807).
J. Berthaud
Winsight
"Eric Belhomme" <{rico}+no/ wrote in message
news:
> Bonjour,
>
> Je suis en train d'étudier une refonte d'un système de BDD installé, et
> notament j'envisage de remplacer les relations actuelles faites par une
> triplette de colonnes CLUSTERED par un id de type IDENTITY :
>
> actuellement j'ai :
>
> trtdate int NOT NULL,
> blocid int NOT NULL,
> docid int NOT NULL,
> ...
> CONSTRAINT [ct_doc_pk] PRIMARY KEY CLUSTERED
> (
> [trtdate],
> [blocid],
> [docid],
> ) WITH FILLFACTOR = 90 ON [PRIMARY]
>
> et je voudrais remplacer ça par :
>
> docid int identity (1,1) NOT NULL,
>
> Cette table va être peuplée de au moins 100 000 000, et va probablement
> décupler. Les questions que je me pose donc sont :
> - quelle est la limite maxi pour une colonne IDENTITY, s'il y en a une ?
> (il n'y a rien à ce sujet dans l'aide de MS SQL)
> - en terme de performances, est-il plus efficace d'utiliser une triplette
> de clés comme c'est fait actuellement, ou vaut-il mieux une clé unique ?
>
> Merci pour vos suggestions ;)
>
> --
> Rico