Discussion :

[Lucas Panny]

Bonjour,

Avant j'utilisais le type GUID comme clé primaire d'une table avec MS SQL où un type spécial "uniqueidentifier" existait. Mais je me creuse de la tête pour faire la même chose sous Oracle, donc j'utiliserais le type VARCHAR2(36) ou VARCHAR2(38) (avec les accolades du GUID) comme équivalence.
Comment faire alors pour faire ce champ qui se donne une valeur toute seule sans qu'on l'ajoute toujours dans la liste des VALUES lors des insertions, je me propose

Code :

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

ID char (36) DEFAULT  SYS_GUID() PRIMARY KEY

mais que contiendra la fonction SYS_GUID()

Et pour un champ de type date + heure, quel est le mieux: DATE ou TIMESTAMP ??

[Vincent Rogier]

Et pour un champ de type date + heure, quel est le mieux: DATE ou TIMESTAMP ??

Les types DATE et TIMESTAMP gèrent tous les deux date+heure.
La différence est que TIMESTAMP permet de gérer la partie fractionnaire des secondes et peut prendre en charge le timezone. De plus, il est aussi fortement couplé au type INTERVAL qui permet de gérer des intervalles entre TIMESTAMPs

Pour gérer date+heure seulement, DATE est le plus simple

[Lucas Panny]

Et pour le GUID en clé primaire ?

[Vincent Rogier]

Pourquoi passer par un guid varchar2(38) ???

Pourquoi pas passer par un simple ID numérique couplé à une séquence ?

Entre un ID de type NUMBER et un ID de type VARCHAR2(38), y a pas photo !

C'est vraiment un pré-requis qui t'es imposé d'avoir un GUID ?

[Lucas Panny]

Une clé primaire en UUID est très familier surtout pour les utilisateurs de BD Sql Server (qui bénéficient du type natif UNIQUEIDENTIFIER) et Access 2003. Et je voudrais tout simplement faire la même chose avec Oracle.
J'ai même trouvé sur le net une fonction pour créer un GUID (http://www.oracle-base.com/articles/9i/UUID9i.php):

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
CREATE OR REPLACE FUNCTION new_uuid RETURN VARCHAR2 AS
  l_seed        BINARY_INTEGER;
  l_random_num  NUMBER(5);
 
  l_date        VARCHAR2(25);
  l_random      VARCHAR2(4);
  l_ip_address  VARCHAR2(12);
BEGIN
  l_seed := TO_NUMBER(TO_CHAR(SYSDATE,'YYYYDDMMSS'));
  DBMS_RANDOM.initialize (val => l_seed);
  l_random_num := TRUNC(DBMS_RANDOM.value(low => 1, high => 65535));
  DBMS_RANDOM.terminate;
 
  l_date       := conversion_api.to_hex(TO_NUMBER(TO_CHAR(SYSTIMESTAMP,'FFSSMIHH24DDMMYYYY')));
  l_random     := RPAD(conversion_api.to_hex(l_random_num), 4, '0');
  l_ip_address := conversion_api.to_hex(TO_NUMBER(REPLACE(NVL(SYS_CONTEXT('USERENV','IP_ADDRESS'), '123.123.123.123'), '.', '')));
 
  RETURN SUBSTR(l_date, 1, 8)                     || '-' ||
         SUBSTR(l_date, 9, 4)                     || '-' ||
         SUBSTR(l_date, 13, 4)                    || '-' ||
         RPAD(SUBSTR(l_date, 17), 4, '0')         || '-' ||
         RPAD(l_random || l_ip_address, 12, '0');
END;
/

Mais comment faire pour que ce champ s'auto-crée !!! Je veux faire:

Code :

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

ID varchar2(38) DEFAULT  new_uuid PRIMARY KEY

mais ça ne passe pas donc faut toujours insérer cette fonction à chaque insertion
Sous MSSQL, on peut faire [ID] [uniqueidentifier] PRIMARY KEY DEFAULT NEWID()

[Vincent Rogier]

Une clé primaire en UUID est très familier surtout pour les utilisateurs de BD Sql Server (qui bénéficient du type natif UNIQUEIDENTIFIER) et Access 2003. Et je voudrais tout simplement faire la même chose avec Oracle.

Ok, mais ma question (et remarque) ne portait sur le fait que MS Server le permet mais sur l'utilité même de gérer un Guid lourd à générer et à stocker et qui lent à indexer... Alors q'un simple NUMBER fait la même chose avec des perfs nettement meilleures !

Sinon, si tu tiens vraiment à utiliser ta fonction, tu peux l'appeler :

• dans le insert
• ou dans un trigger sur on insert

[Lucas Panny]

• ou dans un trigger sur on insert

Comment ?

Il faudrait donc un trigger pour chaque table, quelle poisse !!!

ID varchar2(38) DEFAULT new_uuid PRIMARY KEY

Même Oracle 11g ne peut-il pas faire ça ?

En effet, un GUID est difficile à indexer mais je dois l'utiliser !!!

[orafrance]

sur l'utilité même de gérer un Guid lourd à générer et à stocker et qui lent à indexer...

Si ni plus lourd ni plus lent qu'un NUMBER... en revanche ça évite les contentions sur les séquences et plus important, ça évite les trous

[mnitu]

Si ni plus lourd ni plus lent qu'un NUMBER... en revanche ça évite les contentions sur les séquences et plus important, ça évite les trous

Ca mérite une explication parce que je ne le vois pas (mais pas du tout). C'est quoi un trous dans un GUID ? Et c'est quoi "les contentions" sur les séquences ? Bon sur les tables ça va, mais sur les séquences ?

[orafrance]

une séquence ne garantie pas la perte de valeur, notamment à cause du cache et souffre d'une grosse concurrence d'accès. Les contentions sont du même type que les library cache pin pour les procédures et packages.

[randriano]

En fait c'est ma conclusion, j'utilise VARCHAR2 comme clé primaire, je ne peux pas mettre une fonction qui le génère automatiquement durant CREATE TABLE comme DEFAULT, j'ai envie d'utiliser une contrainte CHECK sur une colonne et ma condition utilise une fonction (ex: MaFonction(colonne1) > 3), ça ne passe pas d'où le fait de toujours mettre un test dans un trigger before insert, c'est la poisse si il y a plus de 100 tables à faire comme ça

[mnitu]

En fait tu parle des functions PL/SQL pour lesquelles, c'est vrai, des restrictions existent

DEFAULT

The DEFAULT clause lets you specify a value to be assigned to the column if a subsequent INSERT statement omits a value for the column. The datatype of the expression must match the datatype of the column. The column must also be long enough to hold this expression.

The DEFAULT expression can include any SQL function as long as the function does not return a literal argument, a column reference, or a nested function invocation.

Restriction on Default Column Values
A DEFAULT expression cannot contain references to PL/SQL functions or to other columns, the pseudocolumns CURRVAL, NEXTVAL, LEVEL, PRIOR, and ROWNUM, or date constants that are not fully specified.

[Lucas Panny]

et pour la contrainte d'intégrité CHECK !!
Est-ce qu'on peut utiliser une fonction que j'ai définie à l'intérieur si ça ne marche pas avec la contrainte DEFAULT ?