Quelques pistes...
Jean-Paul Argudo/ = 27 Mars, 2008 - 13:46
Sauf erreur ou omission de ma part, on ne peut pas le faire.
Le plus simple consiste à modifier vos scripts pour créer des tables sans clés ni index, pour les créer par la suite.
C'est généralement ce qu'on fait. Dans certains cas, c'est même très conseillé.
Par exemple lors de migrations vers PostgreSQL. On créée les tables vides, on importe les données, et on place la(les) clé(s) ensuite (primaire, secondaire) et autres index. Dans ces cas là c'est en effet bien plus performant de créer les index d'un coup...
Un exemple (pour la syntaxe SQL):
create table messageserreurs
(
idmessage integer,
langue integer,
message varchar(255),
ds_replic timestamp default current_timestamp,
ds_insert timestamp default current_timestamp,
ds_update timestamp default current_timestamp
);
[.. plus loin dans le code ..]
alter table messageserreurs
add constraint pkmessageserreurs
primary key (idmessage,langue);
Maintenant, ce n'est qu'une solution. Vous pouvez aussi modifier vos scripts pour laisser PostgreSQL générer les *_pkey et ensuite initier des ALTER INDEX eleves_pkey RENAME TO ce_que_vous_voulez
.
Je n'ai pas non plus la syntaxe du CREATE TABLE
en tête dans tous ses inombrables détails, mais on peut aussi spécifier le PRIMARY KEY
, il faudrait prendre le temps de vérifier si on ne peut pas nommer là directement l'index.
En espérant vous avoir aidé,
--
Jean-Paul ARGUDO
http://dalibo.com | http://dalibo.org
[ Vous devez
vous connecter pour poster des commentaires ]
Nommer les contraintes à la création
SAS/ = 1 Avril, 2008 - 09:18
Bonjour,
Il est tout à fait possible d'imposer le nom d'une clé primaire lors de sa création. Voir le petit exemple qui suit :
sas=# create table matable (id serial, champ text, constraint ma_contrainte primary key (id));
INFO: CREATE TABLE créera des séquences implicites « matable_id_seq » pour la colonne « serial » « matable.id »
INFO: CREATE TABLE / PRIMARY KEY créera un index implicite « ma_contrainte » pour la table « matable »
CREATE TABLE
sas=# \d matable
Table « public.matable »
Colonne | Type | Modificateurs
---------+---------+------------------------------------------------------
id | integer | not null default nextval('matable_id_seq'::regclass)
champ | text |
Index :
« ma_contrainte » PRIMARY KEY, btree (id)
Librement,
Stéphane Schildknecht
dalibo
PostgreSQLFr
[ Vous devez
vous connecter pour poster des commentaires ]
Merci
jonathan.dupre/ = 29 Avril, 2008 - 10:27
Merci Ă vous deux.
Mais en fait j'ai demandé à mon prof qui m'à expliqué que cet index implicit ne concernait le champs que par rapport aux clés étrangères....mais pas sur la table elle-même.
Cet index ne sert que dans le cas ou le champs "SERIAL" (en clé primaire) de la table créée est liée à une autre table, mais en fait il n'y à pas d'index propre pour cette table ci. Je ne sais pas si c'est clair....
Bizarre mais bon... Aucune idée si c'est vrai.
[ Vous devez
vous connecter pour poster des commentaires ]
Clair ? Non !
SAS/ = 29 Avril, 2008 - 14:42
Bonjour,
Votre explication est effectivement peu claire.
Cet index porte sur le(s) champ(s) qui compose(nt) la clé primaire. Il est rattaché à la table qui contient la clé primaire.
Un \d table pourrait vous aider Ă le voir.
Une autre manière de vous convaincre de l'utilisation de cet index lors de requête sur cette table est de réaliser un *explain* d'une requête pour laquelle vous spécifieriez une clause where impliquant ce champ.
Vous verrez qu'il est utilisé pour une parcours d'index utilisant cet index (sous réserve toutefois que le planificateur estime que ce parcours plus efficace qu'un parcours séquentiel de la table...).
Est-ce plus clair pour vous ?
Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr
[ Vous devez
vous connecter pour poster des commentaires ]