Discussion :

[Kineas]

Bonjour à tous,

Dans le cadre de l'optimisation d'une base Oracle, j'aurai une question concernant le type CHAR.
Suite à une analyse de notre base, on nous conseille de remplacer tous nos CHAR par des VARCHAR2. Cependant, nous avons utilisés le type CHAR à bon escient, c'est à dire que nous ne l'avons utilisés que lorsque la valeur était toujours entièrement valorisée et non null. Dans ces cas là, est ce que l'utilisation du VARCHAR2 est utile ? Ou au contraire, comme je le pense, utiliser des VARCHAR2 prendra plus de place en base ?

En fait je vois les choses comme ça :
- CHAR(2) valorisé et non null prend 2 octets en base
- VARCHAR2(2) valorisé et non null prend 2 octets en base + 2 octets pour stocker la longueur, donc 4 octets.
Donc si cela est correct, CHAR(2) est mieux que VARCHAR(2) si la valeur est toujours valorisée.

PS : je suis tombé sur ce lien ici mais je trouve que la réponse n'est pas assez précise, donc j'ai préféré reposer la question

[Waldar]

Non, vous avez tort.

La longueur du char et du varchar existe et est stockée dans les deux types, sur deux octets.
Mais votre char prendra toujours sa longueur maximale, dans votre exemple un char(2) fera toujours 4 octets là où un varchar(2) oscillera entre 3 et 4 octets.

Si vous êtes sûr de votre donnée et que cette dernière fait toujours deux octets, les deux types fonctionneront de manière strictement identique.

Et la petite citation de Tom Kytes (comparaison entre char(10) et varchar2(10), voir ici):

If the field is in fact ALWAYS 10 bytes long, using a CHAR will not hurt -- HOWEVER, it will not help either.

The only time I personally use a CHAR type is for CHAR(1). And that is only because its faster to type char(1) then varchar2(1) -- it offers no advantages.

[Kineas]

Merci beaucoup pour ta réponse rapide
Je vais donc de ce pas changer tous mes CHAR en VARCHAR2

[pacmann]

Salut !

Petite question au passage : quelqu'un sait pourquoi ?

Il paraît que ce n'est pas le cas dans pleins d'autres SGBD... (la longueur n'est pas stockée pour les CHAR)

[mnitu]

Salut !

Petite question au passage : quelqu'un sait pourquoi ?

Il paraît que ce n'est pas le cas dans pleins d'autres SGBD... (la longueur n'est pas stockée pour les CHAR)

Moi je ne crois pas que c'est vrai!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
SQL> create table t_char (a varchar2(2),b char(2));
 
Table crÚÚe.
SQL> insert into t_char values('aa','aa')
  2  ;
 
1 ligne crÚÚe.
 
SQL> commit;
 
Validation effectuÚe.
 
SQL> select dump(a),dump(b) from t_char;
 
DUMP(A)
-------------------------------------------------------------
DUMP(B)
-------------------------------------------------------------
Typ=1 Len=2: 97,97
Typ=96 Len=2: 97,97
 
SQL> insert into t_char values('b','b');
 
1 ligne crÚÚe.
 
SQL> commit;
 
Validation effectuÚe.
 
SQL> select dump(a),dump(b) from t_char where a= 'b';
 
DUMP(A)
---------------------------------------------------------
DUMP(B)
---------------------------------------------------------
Typ=1 Len=1: 98
Typ=96 Len=2: 98,32

Oracle concepts

VARCHAR2 and VARCHAR Datatypes
The VARCHAR2 datatype stores variable-length character strings. When you create a table with a VARCHAR2 column, you specify a maximum string length (in bytes or characters) between 1 and 4000 bytes for the VARCHAR2 column. For each row, Oracle stores each value in the column as a variable-length field unless a value exceeds the column's maximum length, in which case Oracle returns an error. Using VARCHAR2 and VARCHAR saves on space used by the table.

For example, assume you declare a column VARCHAR2 with a maximum size of 50 characters. In a single-byte character set, if only 10 characters are given for the VARCHAR2 column value in a particular row, the column in the row's row piece stores only the 10 characters (10 bytes), not 50.
Oracle compares VARCHAR2 values using nonpadded comparison semantics.

[Waldar]

Pacmann faisait référence aux messages de SQLPro sur ce fil : http://www.developpez.net/forums/d68...d-int-varchar/

Je pense que votre réponse est un peu hors-sujet

[pachot]

Bonjour,
Si la longueur n'est pas stockée, il faut quand même stocker un indicateur pour dire si la valeur est nulle, alors pourquoi pas la longueur (=0 pour null) ?
C'est aussi très pratique et performant pour parcourir des enregistrements de longueur variable dans un bloc. Au lieu d'un séparateur de champ, on met la longueur de chacun et on peut donc passer au suivant directement.
Cordialement,
Franck.