Discussion :

[JUSTIN Loïc]

Bonjour,
je suis toujour dans mon transfert d'une base POSTGRESQL vers Oracle,
mais j'ai un probleme avec une table qui posséde une colonne de type TIME et je ne vois pas quel type mettre dans la base Oracle. Les donnees sont du type

23:02:00

Si quelqu'un a une idee, je suis preneur.

Cordialement

[Pomalaix]

Bonjour

L'aspect des données est secondaire, ce qui compte c'est leur signification.
"23:02:00" représente-t-il une date, ou une durée ?

Dans le premier cas, il faudra utiliser un type DATE, en restituant la partie année-mois-jour ; dans le second, c'est probablement le type INTERVAL DAY TO SECOND qui conviendra.

[remi4444]

Attention au type date pour le stockage des heures parcque par défaut oracle, va te mettre le 1ier jour du mois courant en date du jour. Et donc apres c'est galère quant on veut faire des classement, c'est pas indexable et en plus ça prend de la place pour rien...

[LeoAnderson]

Attention au type date pour le stockage des heures parcque par défaut oracle, va te mettre le 1ier jour du mois courant en date du jour. Et donc apres c'est galère quant on veut faire des classement, c'est pas indexable et en plus ça prend de la place pour rien...

et vous préconisez quoi ?
3 champs numériques pour heures, minutes, secondes ?

[JUSTIN Loïc]

Bonjour,
23:02:00 représente l'heure de lancement d'une sauvegarde
pour complément voici la structure de la table postgresql

id_strat int4,
dates date,
debut time,
frequence interval,
retention interval,
taux_echec real,
vol_moyen int4,
deb_moyen real,
dur_moyen interval,
att_moyen interval,
nb_sauve int4
nb_err int4
volume_mo int4,
UNIQUE (id_strat,date)

voici ici un enregistrement complet

INSERT INTO ma_table (id_strat,dates,debut,frequence,retention,taux_echec,vol_moyen,deb_moyen,dur_moyen,nb_sauve,nb_err,volume_mo) VALUES (72532, '2003-03-28','20:00:00','6 days 23:00:00','16 days',0,3334,1.05,'00:53:00','00:00:00',NULL, NULL, NULL)

De plus, Il faut pouvoir faire un tri sur l'heure de lancement donc la colonne debut est necessaire.

J'espère avoir été plus explicite.

[orafrance]

et vous préconisez quoi ?
3 champs numériques pour heures, minutes, secondes ?

et un 4° pour les millisecondes

[remi4444]

J'avoue être un peu à la ramasse sur les nouveaux types de la 10g donc y'a peut-etre plus idéal que ce que je vais dire...

Si tu veux pas t'embêter et que tu n'a pas de problème de place, reste en varchar2(8). C'est tout bien formaté, et le calssement est respecté, c'est facilement indexable.

Si il faut vraiment optimiser au maximum, tu peux le stocker en tant que "nombre de secondes depuis minuit", et comme y'en à 86400 dans une journée, ça donne un number(5). Mais évidement, il faut à chaque fois formater et dé-formater...

[JUSTIN Loïc]

Ok merci,
Je vais tester tes deux propositions pour voir laquelle des deux est la plus simple à mettre en oeuvre.

[LeoAnderson]

Mais pourquoi réinventer la poudre !!!

S'il n'y a que l'heure qui vous intérêsse, prenez une DATE et si cela vous amuse, fixez-vous arbitrairement une date...
Si vous voulez aussi la date de la sauvegarde, prenez une DATE !

Au passage, si on a inventé d'autres types que VARCHAR, c'est pas pour rien !!!
(parce que votre varchar, qu'est-ce qui m'empêche de mettre 00h24 ou 00:24 ou même 18g69 ou même AERYf ....)

[remi4444]

Je suis d'accord sur le principe mais le danger réside dans l'implémentation automatique d'oracle qui met le 1ier jour du mois. Ce qui fait que vous avez une applicaition qui va fonctionner un mois, et le mois suivant qui va planter... j'en ai vu plus d'une....
Effectivement, il faut se fixer une date et s'y tenir, par exemple, si on choisi comme point date référence le 01/01/2000: entrer une heure dans un champ date ne devra surtout pas se faire de la manière suivante:

Code :

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

champ_date := to_date('23:15:00','HH24:MI:SS')

mais:

Code :

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

champ_date := to_date('01/01/2000 23:15:00','DD/MM/YYYY HH24:MI:SS')

pour rentrer l'heure courrante il ne faut surtout pas faire le naturel:

Code :

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

champ_date := sysdate

mais:

Code :

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

champ_date := to_date('01/01/2000 '||to_char(sysdate,'HH24:MI:SS'),'DD/MM/YYYY HH24:MI:SS')

ou bien (un peu plus propre):

Code :

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

champ_date := to_date('2000','YYYY') + (sysdate - trunc(sysdate))

J'ai du mal à avoir une opinion, je ne trouve aucune des solutions tres propres...

[laurentschneider]

....

pour rentrer l'heure courante ...

Code :

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

champ_date := to_date('2000','YYYY') + (sysdate - trunc(sysdate))

J'ai du mal à avoir une opinion, je ne trouve aucune des solutions tres propres...

Je suis assez d'ac avec toi Rémy sur ce point. Ce n'est vraiment pas très lisible comme code, mais ça reste plus zen que de mettre des heures dans des chaines de charactères, non?

c'est vrai que le type TIME manque en oracle, en ce qui concerne les datatypes pour les colonnes.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SQL> select time '12:34:56' t  from dual;
 
T
--------------------
12:34:56,000000000
 
SQL> create table t as select time '12:34:56' t  from dual;
create table t as select time '12:34:56' t  from dual
*
ERREUR à la ligne 1 :
ORA-00902: type de données non valide

[remi4444]

mais ça reste plus zen que de mettre des heures dans des chaines de charactères, non?

Je n'ai pas d'opinion tranchée, je donnais simplement des contres-arguments. Et tout comptes faits, je trouve que en l'absence de solution propre, autant faire la plus simple à implémenter. Effectivement il y a le risque de mettre des donnée invalides, mais tout comptes faits, il est plus facile de détecter une donnée invalide qu'une donnée valide... mais fausse...

[pifor]

Est-ce que le type INTERVAL DAY TO SECOND n'est pas une solution à l'absence de type TIME comme proposé ici dans le 2ème message de http://asktom.oracle.com/pls/ask/f?p...10729709873260 ?

[JUSTIN Loïc]

Bonjour,
merci à ceux qui ont bien voulu se pencher sur mon problème. C'est vrai que le type TIME dans ORACLE s'est vraiment un manque . Je vais tester vos différentes propositions sachant qu'il va falloir adapter les scripts d'insertion de données existant. Ce n'est pas toujours simple.

[remi4444]

Est-ce que le type INTERVAL DAY TO SECOND n'est pas une solution à l'absence de type TIME comme proposé ici dans le 2ème message de http://asktom.oracle.com/pls/ask/f?p...10729709873260 ?

Effectivement, ça a l'air d'être théoriquement le mieux adapté, mais l'utilisation ne me semble couler de source non plus... à la limite peut être que l'implémentation la plus pure est le nombre décimal allant de 0 à 1, pour rester dans l'esprit des intervalles. J'hésite sur la précision mais disons par exemple un NUMBER(9,9).

pour mettre une heure dans ce type de champ:

Code :

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

champ_heure:= to_date('23:25:00','HH24:MI:SS') - to_date('00:00:00','HH24:MI:SS')

Pour mettre l'heure courante:

Code :

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

champ_heure:= sysdate - trunc(sysdate)

pour restituer à l'affichage :

Code :

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

affichage := to_char(trunc(sysdate) + champ_heure,'HH24:MI:SS')

Le principal interret est qu'il y a un sens à combiner ce type d'implémentation avec d'autres champs date.

On peut alors facilement décomposer un champ date_time (par exemple le sysdate) en 2:

Code :

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

1
2
champ_date := trunc(sysdate);
champ_heure := sysdate - champ_date;

Et surtout pour reconstistuer la date/heure, ça devient naturel:

Code :

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

champ_date_heure := champ_date + champ_heure

[laurentschneider]

Le grand avantage de date, c'est qu'on peut le formater avec TO_CHAR, selon si l'on veut les secondes, les minutes, etc...