Discussion :

[Mike@Nestor]

Bonjour,
dans une table, je souhaite définir une colone texte insensible à la casse avec l'attribut UNIQUE

j'aimerai pouvoir définir cela avec la norme SQL.
j'utilise PostgreSQL comme SGBD mais j'aimerai avoir un code standard de création de mes tables.

Ma colonne est actuellement définie en varchar(32), si je met l'attribut UNIQUE, cela fonctionne mais c'est sensible à la casse.

merci
Mike

[Fabien Celaia]

Impossible de créer une unicité d'un champ TEXT. L'unicité est assurée par un index unique, et il n'est pas possible d'indexer un champ de type TEXT

[Mike@Nestor]

Salut fadace !

comment ca il n'est pas possible d'indexer un champ de type text ?

on peut bien definir un index sur un champ de type texte pour effectuer des recherches ?

l'attribut UNIQUE fonctionne aussi sur le varchar mais est sensible à la casse.

[SQLpro]

Encore une fois ABSOLUMENT PAS. Les Blobs ne sont pas indexables par nature, on ne peut donc ni les utiliser comme clef primaire ni comme unique.

En revanche dans certains SGBDR, comme c'est prévue par la norme, on peut mettre en place une indexation textuelle ce qui n'est pas la même chose.

A +

[Mike@Nestor]

cela veut donc dire que ce qui fonctionne pour l'instant avec postgre sql ne fonctionnera pas avec un autre sgbd ?

car actuellemnt dans PostGreSQL j'ai des tables avec des identifiants uniques style GUID (je n'utilise pas l'attribut unique, par def un guid est unique)
Je n'utilise pas de type GUID mais un type char(32) dans lequel je mets mes guid. Je fais cela car le type guid n'est pas reconnu par toutes les bases donc je me suis dis que tant pis, ce serait au moins standard entre toutes les bases de pouvoir rechercher sur des clés texte.
Je me suis completement planté en faisant cela ??

pour l'instant tout fonctionne pour le mieux

[SQLpro]

Non, tu pose mal tes question par manque de culture !!!!

Une colonne (on ne parle pas de champs en matière de SGBDR un champ c'est sur les IHM) de type TEXT c'est un blob de longeur illimité (2 Go). Ce n'est pas la même chose qu'un CHAR ou un VARCHAR... sui représente une chaine de caractères.

A lire sur les types de données SQL :
http://sqlpro.developpez.com/cours/s...ndements/#L6.4

Maintenent l'idée géniale de prendre des GUID pour des clefs et notamment des les encpsauler dans du CHAR (donc avec collation) c'est particulièrement mauvais en terme de performance : 16 octets de caractères avec collation cela fait pas loin de 16 fois plus de boulot pour le processeur pour lire chaque GUID comparé à un entier 32 bits. Sur des tables de millions de lignes et à fortiori sur des recherches et des jointures, je te laisse imaginer les dégâts !!!

A +

[Mike@Nestor]

Excuse moi pour mon manque de culture concernant la bdd, c vrai que ce n'est pas ma tasse de thé ... mais il faut faire avec ;o)

ok bien compris pour les blob, char et autres....

Concernant l'idee "geniale" de gerer des guids comme des chaines de caracteres je suis tout a fait d'accord avec toi que cela n'est pas tres performant. Maintenant je ne fais pas d'applications avec de lourdes bases (pas bcp de tables, pas bcp d'enregistrement). Donc pour mes besoins cela suffit pour l'instant.
De plus le type GUID n'etant pas géré par tous les sgbd, et voulant avoir une base la plus standard possible pour m'affranchir du type de server, les chaines m'ont paru la meilleure solution. Mais si tu as des conseils je suis preneur
Un GUID est defini sur 16 octets, comment faire pour le gerer avec autre chose que le type GUID ? J'ai essayé de passer par une colonne de type binaire mais je trouve ca galere a gerer

Pour ce qui est de definir une colonne de type varchar de maniere unique et insensible a la casse, il y a t-il un moyen ?

merci
Mike

[SQLpro]

C'est une ENORME connerie que de prendre du CHAR et de penser être portable en clef sur tous les SGBDR. Le char va dépndre du jeu de caractères de l'installationet des collations. Ainsi un même SGBDR sous Unix en install standard ne sera pas comptabible avec sa version windows. La réponse a de telles requêtes ne donnera pas le m^me jeu de résultat. Seul les numériques exacts permettent d'avoir cette intéropérabilité.

mais après tout fait ce que tu veut, mais ne demande pas de conseils !

PS : c'est chiant de devoir toujours répondre les mêmes choses tout le temps... Au bout d'un moment on se lasse !

A +

[Mike@Nestor]

je demandais conseil, je le repete je ne suis pas un pro de la bdd (et je ne souhaite pas le devenir) et je cherchais une solution rapide pour de petites bases.
Excuses moi donc de poser des questions idiotes a ton sens.
Merci qd meme.