j'ai un souci avec ce $£§!%* d'Oracle : j'importe dans une table des données en provenance d'un autre SGBF, qui gère les datetime à la milliseconde près. Ce champ étant un champ critique, je souhaite lui coller un index et j'obtiens un merveilleux "ORA-01452: cannot CREATE UNIQUE INDEX; duplicate keys found"
diantre me dis-je ! des clés dupliquées ! et là, je me souviens que les datetime d'Oracle vont jusqu'à la seconde, me voila dans la merde !
 
qwechtieunne :  
- comment pourrais-je simuler un datetime à la milliseconde ?
- comment indexer ce truc ?

au pire, tu peux créer un champ supplémentaire pour y mettre les millisecondes qui débordent et utiliser le doublet comme clé, non?

Bon j'ai pas oracle sous la main mais
si tu transformes ton datetime_millisecondes  
en chaine de caractères, tu peux sans doute importer
la première partie datetime_secondes dans un
nouveau champ et la partie restante millisecondes dans un
autre champ ... puis créer un index unique sur  
ces 2 champs, non ?

Grillaid !

Question subsidiaire: t'as vraiment besoin que l'index soit unique?
 
PS: et le coup de la fille, on me l'a déjà fait, ca marche pas avec moi

c'était ma 1ere idée, je l'ai testé, mais ça me pénalise énormément au niveau vitesse
c'est une table de plus de 10 millions d'enregistrements
 

non, et ça m'a donné une idée : si je créé une surrogate key rattachée à une séquence, ça me permet d'avoir une clé unique, avec un index non unique. ça te semble viable ?

oui, mais encore faut-il voir si ta clef unique va être utilisée dans une relation, sinon tu n'as même pas besoin d'elle.

sauf erreur de ma part : à partir de la version 9 (peut etre en 8i, à vérifier), le type de données TIMESTAMP permet de répondre à tes besoins.....il fonctionne comme le type DATE mais permet la gestion des fractions de seconde.

oui, enfin, on peut supposer que harko s'y connait suffisament pour avoir cherché si timestamp existait dans sa version d'Oracle avant de poser sa question. non?

HEUH LE COUP DE LA BLONDE A FORTE POITRINE POUR APPATER LE CHALAND? C COPYRIGHT(MOI)

n'existe pas sur 8i

"les bonnes idées sont faites pour être réutilisées" (c) moi

8i n'est plus supporté, passe à 9i ou 10chépakellelettre et fais pas chier!

10g
 
Pourquoi pas un NUMBER(17) et stocker la date sous forme aaaammjjhhmissdcm?
 
Qui a dit barbare?

t'as essayé d'enlever le UNIQUE dans "CREATE UNIQUE INDEX" ?
t'as besoin de la milliseconde ou c'est juste pour que ça soit comme avant ?

ben +1 avec mareek , t'as pas l'air de faire la différence entre index et clé unique
 
(et qui c'est les guignols qui proposent d'ajouter les millisecondes pour solutionner ce problème? en quoi ça va rendre les timestamps unique? )

 
Guignols oui ... mais de l'info    
 
Ecoute mon gros   si tas d'un coté base X un
timestamp TX à la milliseconde qui joue le rôle de clé unique
et de l'autre  base Y des timestamp limités à la seconde TY, la soluce
la + évidente est de découper TX en TY + TZ  
 
Maintenant à question générale ... réponse générale    
 

euh, je n'avais pas saisi que la base d'origine avait une clé unique sur cette fameuse colonne timestamp.
c'est bien CA ce que je trouve idiot hein

Mettre le timestamp en clef c'est stupide
La meilleur chose à faire, c'est de mettre la clef sur un entier lié à une séquence.

 
+1 Mais je suis d'accord avec toi Mareek  
 
Mais bon au départ on parlait d'unique index qui marchait pas
car dans la cible on tronquait les millisecondes et donc
ça créait des doublons ...
 

moi je suis ++ avec ceux qui pense qu'une clé unique sur un tel champ est dangereux (je ne remet par contre pas en compte d'utilité de stocker à la milliseconde près )

et une fois de plus tu nous montre la que tu n'as aucune connaissance du fonctionnement d'un vrai sgbd

explique-toi stp

je suis le stagiaire d'harko, je n'ai pas a m'expliquer

ça c'est constructif comme intervention. ça représente bien le personnage.
 
tiens, j'ai une chanson pour toi :
 

 
Merci beaucoup pour ta belle performance tout de même
 
En tout cas, une chose me rassure : je n'ai fait que confirmer les dires de deux personnes qui s'y connaissent assez bien, pour une fois mise à part toi, on me foutra peut-être la paix.

ah oui ? et bien moi je te dédie celle la

 
et je te prends au ping pong quand tu veux.

c'est le topic de "ton maître de stage" qu'on pollue là, moi je m'en fous à la base.

bon on va pas épiloguer hein ! je me suis démerdé avec une surrogate key, ça marche très bien et voila !
quand au fait de mettre un index unique, et autres trucs qui vous paraissent bizarres, c'est juste qu'on m'a demandé de transférer des données venant d'une base DB2 vers une base Oracle et de respecter le plus possible la structure (donc de garder les indexes, et tout). maintenant, pourquoi mettre un index sur le timestamp, c'est parce que la base d'origine en possède un et puis voilà. apparemment l'application hote permet de rechercher des infos selon le critère de l'heure, d'ou la présence de l'index.
 
et pour répondre à moins moins : bien sur que je connais la différence entre index unique et clé unique

pas de souci pour les explications harko celà dit, je reste sceptique quant à la véritable utilité d'un index unique sur ce type de champ, par rapport au risque de violation de clé.
par simple curriosité, c'est quoi comme infos ?

DB2 vers Oracle...
 
 j'ai deja fait une fois, joli bordel a faire , mais ca fonctionnait

ce sont des infos boursières, donc des données très critiques au niveau de la date et de l'heure
"taiiiinnnnn, mon action a perdu 10 € depuis 9:02:04.125 "
"dommage, t'aurais du vendre, elle était à 40 € à 05:14:06.187 "

tu m'étonnes que c'est un joli bordel
 
edit: surtout que je bosse sur 8i

ok. ça me semble bizarre qu'on ne risque pas d'avoir de boublon sur ce type d'infos
 
mais bon, si l'ancien système tournait correctement avec un index unique, pourquoi pas
 
PS: si tu rédiges un compte rendu de migration, je te conseille d'y relater ce point, histoire que ça te retombe pas dessus si avec la nouvelle base ça merde

bin stocke la sous forme de chaine de caractere en utilisant QueryPerformanceCounter pour avoir une précision de ouf

ouais m'enfin vive les performances, passer d'un type float (en interne, une date n'est ni plus ni moins qu'un float) à un type non pondéré...
 
ceci dit, si les dates en question ne contiennent que la partie horraire, why not, puisque de toute façon, la décimale au niveau d'un datetime se fait entre la partie date et la partie horraire.

déjà fait, parce que j'ai rencontré des merdes encore pires que celle pour laquelle j'ai ouvert ce topic ! j'ai pas envie que tout le monde me tombe dessus parce que leur portefeuille se casse la gueule

va bosser chez microsoft ils ont de bons avocats...

c'est sûr qu'en plus, quand il s'agit de portefeuil d'actions, t'auras certainement du mal à dédomager une personne avec les 3 euros qui doivent traîner sur ton compte courrant

euh tu le fais expres?
index != clé unique.
tu dis que y'avait un index et tu parles d'en faire une clé unique, y'a de quoi se poser des questions non?

ca me fait peur oracle...si j'arrive à faire mon stage où je veux, je risque d'avoir à migrer une base SQL server vers de l'Oracle (du 9i ou + j'espère) ...et sortir de l'asp vers du JSP...
 
ca va etre fun et bigarré...