je viens d'un autre SGBD, et j'avais l'habitude de toujours séparer dans des
fichiers différents (et sur des disques différents) les DATA des INDEX.
J'ai vu que sous SQL 2K, on pouvait faire la même chose via les groupes de
fichiers. Pas de problème pour les index, mais concernant la clé primaire
(ou en tout cas toute clé CLUSTERED), je ne peux que spécifier le groupe de
fichier correspondant aux données de la table.
J'ai bien compris qu'en cas de clé CLUSTERED, ce sont directement les
données qui sont triées, mais SQL stocke bien quelque-part un B-TREE
indexant les pages.
On ne peut donc pas préciser un groupe de fichiers pour ce B-TREE ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
Bonjour,
Un index CLUSTER comprend toutes les données de la table. C'est donc "la table". Dans le cas d'un index cluster, le B-TREE contient donc les données de toutes les colonnes de la table (la ligne complète). Mettre tous les index, y compris les cluster sur un fichier n'a pas d'intérêt. Il convient donc de mettre tous les index non clustered (en "heap") sur le fichier d'index et les tables ou les index cluster sur le fichier de données.
La bonne question en supplément est de se demander si l'on a toujours intérêt à utiliser un index CLUSTER pour toute les clefs de toutes les tables (paramétrage par défaut). En fait le cluster n'a d'intérêt que si la clef est ordonné dans le temps => clef historisation ou auto incrément. Dans tous les autres cas, se poser la question.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Timur a écrit:
Bonjour,
je viens d'un autre SGBD, et j'avais l'habitude de toujours séparer dans des fichiers différents (et sur des disques différents) les DATA des INDEX.
J'ai vu que sous SQL 2K, on pouvait faire la même chose via les groupes de fichiers. Pas de problème pour les index, mais concernant la clé primaire (ou en tout cas toute clé CLUSTERED), je ne peux que spécifier le groupe de fichier correspondant aux données de la table. J'ai bien compris qu'en cas de clé CLUSTERED, ce sont directement les données qui sont triées, mais SQL stocke bien quelque-part un B-TREE indexant les pages.
On ne peut donc pas préciser un groupe de fichiers pour ce B-TREE ?
Merci de vos éclaircissements.
Bonjour,
Un index CLUSTER comprend toutes les données de la table. C'est donc "la table".
Dans le cas d'un index cluster, le B-TREE contient donc les données de toutes
les colonnes de la table (la ligne complète).
Mettre tous les index, y compris les cluster sur un fichier n'a pas d'intérêt.
Il convient donc de mettre tous les index non clustered (en "heap") sur le
fichier d'index et les tables ou les index cluster sur le fichier de données.
La bonne question en supplément est de se demander si l'on a toujours intérêt à
utiliser un index CLUSTER pour toute les clefs de toutes les tables (paramétrage
par défaut).
En fait le cluster n'a d'intérêt que si la clef est ordonné dans le temps =>
clef historisation ou auto incrément. Dans tous les autres cas, se poser la
question.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Timur a écrit:
Bonjour,
je viens d'un autre SGBD, et j'avais l'habitude de toujours séparer dans des
fichiers différents (et sur des disques différents) les DATA des INDEX.
J'ai vu que sous SQL 2K, on pouvait faire la même chose via les groupes de
fichiers. Pas de problème pour les index, mais concernant la clé primaire
(ou en tout cas toute clé CLUSTERED), je ne peux que spécifier le groupe de
fichier correspondant aux données de la table.
J'ai bien compris qu'en cas de clé CLUSTERED, ce sont directement les
données qui sont triées, mais SQL stocke bien quelque-part un B-TREE
indexant les pages.
On ne peut donc pas préciser un groupe de fichiers pour ce B-TREE ?
Un index CLUSTER comprend toutes les données de la table. C'est donc "la table". Dans le cas d'un index cluster, le B-TREE contient donc les données de toutes les colonnes de la table (la ligne complète). Mettre tous les index, y compris les cluster sur un fichier n'a pas d'intérêt. Il convient donc de mettre tous les index non clustered (en "heap") sur le fichier d'index et les tables ou les index cluster sur le fichier de données.
La bonne question en supplément est de se demander si l'on a toujours intérêt à utiliser un index CLUSTER pour toute les clefs de toutes les tables (paramétrage par défaut). En fait le cluster n'a d'intérêt que si la clef est ordonné dans le temps => clef historisation ou auto incrément. Dans tous les autres cas, se poser la question.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Timur a écrit:
Bonjour,
je viens d'un autre SGBD, et j'avais l'habitude de toujours séparer dans des fichiers différents (et sur des disques différents) les DATA des INDEX.
J'ai vu que sous SQL 2K, on pouvait faire la même chose via les groupes de fichiers. Pas de problème pour les index, mais concernant la clé primaire (ou en tout cas toute clé CLUSTERED), je ne peux que spécifier le groupe de fichier correspondant aux données de la table. J'ai bien compris qu'en cas de clé CLUSTERED, ce sont directement les données qui sont triées, mais SQL stocke bien quelque-part un B-TREE indexant les pages.
On ne peut donc pas préciser un groupe de fichiers pour ce B-TREE ?
Merci de vos éclaircissements.
Timur
Merci Fred pour ces précisions.
je comprend tout à fait que les *feuilles* du BTREE soient la table elle-même. Mais il y a bien quand même des niveau supérieurs d'index qui pointent vers ces feuilles, non ?
Encore plus bizarre : Enterprise Manager ne permet pas (zone grisée) de sélectionner d'autre groupes que le groupe des données de la table. Par contre, avec le script suivant :
CREATE TABLE dbo.TBLSTRUCTURE ( ID int NOT NULL IDENTITY (1, 1), valeur varchar(200) NULL ) ON GrpStructure_data GO
ALTER TABLE dbo.TBLSTRUCTURE ADD CONSTRAINT PK_TBLSTRUCTURE PRIMARY KEY CLUSTERED ( ID ) ON GrpStructure_ind
on parvient à créer sans erreur la PK CLUSTERED dans un autre groupe que celui de la table.
Après vérification dans sysindexes, la PK est bien dans le groupe GrpStructure_ind !
Alors on peut, ou on peut pas ??? ;-)
Sinon, bien noté sur la pertinence de la clé clustered. J'en suis aux "cas d'école" pour retrouver mes marques par rapport à mon expérience.
-- Cordialement
"Fred BROUARD" a écrit dans le message de news:
Bonjour,
Un index CLUSTER comprend toutes les données de la table. C'est donc "la
table".
Dans le cas d'un index cluster, le B-TREE contient donc les données de
toutes
les colonnes de la table (la ligne complète). Mettre tous les index, y compris les cluster sur un fichier n'a pas
d'intérêt.
Il convient donc de mettre tous les index non clustered (en "heap") sur le fichier d'index et les tables ou les index cluster sur le fichier de
données.
La bonne question en supplément est de se demander si l'on a toujours
intérêt à
utiliser un index CLUSTER pour toute les clefs de toutes les tables
(paramétrage
par défaut). En fait le cluster n'a d'intérêt que si la clef est ordonné dans le temps
=>
clef historisation ou auto incrément. Dans tous les autres cas, se poser
la
question.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Timur a écrit: > Bonjour, > > je viens d'un autre SGBD, et j'avais l'habitude de toujours séparer dans
des
> fichiers différents (et sur des disques différents) les DATA des INDEX. > > > J'ai vu que sous SQL 2K, on pouvait faire la même chose via les groupes
de
> fichiers. Pas de problème pour les index, mais concernant la clé
primaire
> (ou en tout cas toute clé CLUSTERED), je ne peux que spécifier le groupe
de
> fichier correspondant aux données de la table. > J'ai bien compris qu'en cas de clé CLUSTERED, ce sont directement les > données qui sont triées, mais SQL stocke bien quelque-part un B-TREE > indexant les pages. > > On ne peut donc pas préciser un groupe de fichiers pour ce B-TREE ? > > > > Merci de vos éclaircissements. > >
Merci Fred pour ces précisions.
je comprend tout à fait que les *feuilles* du BTREE soient la table
elle-même. Mais il y a bien quand même des niveau supérieurs d'index qui
pointent vers ces feuilles, non ?
Encore plus bizarre : Enterprise Manager ne permet pas (zone grisée) de
sélectionner d'autre groupes que le groupe des données de la table.
Par contre, avec le script suivant :
CREATE TABLE dbo.TBLSTRUCTURE
(
ID int NOT NULL IDENTITY (1, 1),
valeur varchar(200) NULL
) ON GrpStructure_data
GO
ALTER TABLE dbo.TBLSTRUCTURE
ADD CONSTRAINT PK_TBLSTRUCTURE PRIMARY KEY CLUSTERED
(
ID
) ON GrpStructure_ind
on parvient à créer sans erreur la PK CLUSTERED dans un autre groupe que
celui de la table.
Après vérification dans sysindexes, la PK est bien dans le groupe
GrpStructure_ind !
Alors on peut, ou on peut pas ??? ;-)
Sinon, bien noté sur la pertinence de la clé clustered. J'en suis aux "cas
d'école" pour retrouver mes marques par rapport à mon expérience.
--
Cordialement
"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de
news:u1kL3eevFHA.2864@TK2MSFTNGP10.phx.gbl...
Bonjour,
Un index CLUSTER comprend toutes les données de la table. C'est donc "la
table".
Dans le cas d'un index cluster, le B-TREE contient donc les données de
toutes
les colonnes de la table (la ligne complète).
Mettre tous les index, y compris les cluster sur un fichier n'a pas
d'intérêt.
Il convient donc de mettre tous les index non clustered (en "heap") sur le
fichier d'index et les tables ou les index cluster sur le fichier de
données.
La bonne question en supplément est de se demander si l'on a toujours
intérêt à
utiliser un index CLUSTER pour toute les clefs de toutes les tables
(paramétrage
par défaut).
En fait le cluster n'a d'intérêt que si la clef est ordonné dans le temps
=>
clef historisation ou auto incrément. Dans tous les autres cas, se poser
la
question.
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Timur a écrit:
> Bonjour,
>
> je viens d'un autre SGBD, et j'avais l'habitude de toujours séparer dans
des
> fichiers différents (et sur des disques différents) les DATA des INDEX.
>
>
> J'ai vu que sous SQL 2K, on pouvait faire la même chose via les groupes
de
> fichiers. Pas de problème pour les index, mais concernant la clé
primaire
> (ou en tout cas toute clé CLUSTERED), je ne peux que spécifier le groupe
de
> fichier correspondant aux données de la table.
> J'ai bien compris qu'en cas de clé CLUSTERED, ce sont directement les
> données qui sont triées, mais SQL stocke bien quelque-part un B-TREE
> indexant les pages.
>
> On ne peut donc pas préciser un groupe de fichiers pour ce B-TREE ?
>
>
>
> Merci de vos éclaircissements.
>
>
je comprend tout à fait que les *feuilles* du BTREE soient la table elle-même. Mais il y a bien quand même des niveau supérieurs d'index qui pointent vers ces feuilles, non ?
Encore plus bizarre : Enterprise Manager ne permet pas (zone grisée) de sélectionner d'autre groupes que le groupe des données de la table. Par contre, avec le script suivant :
CREATE TABLE dbo.TBLSTRUCTURE ( ID int NOT NULL IDENTITY (1, 1), valeur varchar(200) NULL ) ON GrpStructure_data GO
ALTER TABLE dbo.TBLSTRUCTURE ADD CONSTRAINT PK_TBLSTRUCTURE PRIMARY KEY CLUSTERED ( ID ) ON GrpStructure_ind
on parvient à créer sans erreur la PK CLUSTERED dans un autre groupe que celui de la table.
Après vérification dans sysindexes, la PK est bien dans le groupe GrpStructure_ind !
Alors on peut, ou on peut pas ??? ;-)
Sinon, bien noté sur la pertinence de la clé clustered. J'en suis aux "cas d'école" pour retrouver mes marques par rapport à mon expérience.
-- Cordialement
"Fred BROUARD" a écrit dans le message de news:
Bonjour,
Un index CLUSTER comprend toutes les données de la table. C'est donc "la
table".
Dans le cas d'un index cluster, le B-TREE contient donc les données de
toutes
les colonnes de la table (la ligne complète). Mettre tous les index, y compris les cluster sur un fichier n'a pas
d'intérêt.
Il convient donc de mettre tous les index non clustered (en "heap") sur le fichier d'index et les tables ou les index cluster sur le fichier de
données.
La bonne question en supplément est de se demander si l'on a toujours
intérêt à
utiliser un index CLUSTER pour toute les clefs de toutes les tables
(paramétrage
par défaut). En fait le cluster n'a d'intérêt que si la clef est ordonné dans le temps
=>
clef historisation ou auto incrément. Dans tous les autres cas, se poser
la
question.
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Timur a écrit: > Bonjour, > > je viens d'un autre SGBD, et j'avais l'habitude de toujours séparer dans
des
> fichiers différents (et sur des disques différents) les DATA des INDEX. > > > J'ai vu que sous SQL 2K, on pouvait faire la même chose via les groupes
de
> fichiers. Pas de problème pour les index, mais concernant la clé
primaire
> (ou en tout cas toute clé CLUSTERED), je ne peux que spécifier le groupe
de
> fichier correspondant aux données de la table. > J'ai bien compris qu'en cas de clé CLUSTERED, ce sont directement les > données qui sont triées, mais SQL stocke bien quelque-part un B-TREE > indexant les pages. > > On ne peut donc pas préciser un groupe de fichiers pour ce B-TREE ? > > > > Merci de vos éclaircissements. > >
