|
Bas de page | |
---|---|
Auteur | Sujet : CRC32 identique pour 2 strings différents. |
Publicité | Posté le 09-02-2012 à 17:16:11 |
Zzozo Un peu, passionément, à la fol |
--------------- « Ce qui ne vous tue pas vous rend plus fort » F. Nietzsche | « Vise_ la Lune. Si tu rates, au pire, t'es dans la merde » Un poète disparu dans le cercle |
Sebastien | Pas sur d'avoir bien compris ta question sur la logique de mise à jour.
Message cité 1 fois Message édité par Sebastien le 10-02-2012 à 00:52:27 |
Zzozo Un peu, passionément, à la fol |
Par contre, j'ai qq doutes sur ce que j'ai compris ... Pas moyen d'utiliser un ou deux triggers bien "sentis" plutot que votre mécanisme actuel ? C'est vraiment nécessaire d'utiliser une clé primaire généré par hachage ? elle peut pas être générée de façon indépendante (et surtout unique) lors de la création des enregistrements dans la nouvelle table ? Ca me parait compliqué cette histoire de clé primaire "technique"/étrangère générée en hachant une "clé fonctionnelle" existante, alors que la génération/gestion auto d'une clé primaire sur une table, c'est une des fonctionnalités de base de tout SGBDR qui se respecte Ou alors il doit me manquer des contraintes dues à l'existant/projet non expliquées ici. EDIT : en y réfléchissant bien, y'a même pas besoin de trigger en fait EDIT2 : "référentiel volumineux" => ça veut dire quoi ? (juste un ordre d'idée en millions/centaine de millions de lignes) Message édité par Zzozo le 10-02-2012 à 13:06:08 --------------- « Ce qui ne vous tue pas vous rend plus fort » F. Nietzsche | « Vise_ la Lune. Si tu rates, au pire, t'es dans la merde » Un poète disparu dans le cercle |
Publicité | Posté le 10-02-2012 à 14:28:07 |
Zzozo Un peu, passionément, à la fol |
--------------- « Ce qui ne vous tue pas vous rend plus fort » F. Nietzsche | « Vise_ la Lune. Si tu rates, au pire, t'es dans la merde » Un poète disparu dans le cercle |
Zzozo Un peu, passionément, à la fol |
EDIT : et pour gérer les updates dans le bon ordre, faut ajouter une colonne timestamp ou un truc dans le genre dans la table temporaire, pour être sur de les faire dans l'ordre lors des différents SELECT (y'aura juste à rajouter une clause ORDER BY )
Le truc que j'ai proposé se fait en un bloc, c'est pas un curseur. Si c'est pas le cas, vous avez un pb plus grave sur les bras, vous n'avez personne dans votre équipe qui s'y connaisse vraiment en SQL mais surtout en SGBDR / modélisation de S.I./BDD . En attendant, vous pouvez pas aller voir les DBA/l'équipe de prod pour discuter de votre MPD et voir s'ils peuvent vous aider à corriger les erreurs qu'ils voient ? Parce que là, plus ça avance, plus je découvre que votre MPD est bancal Ce sont les fondations. Désolé, je suis un peu rude là, mais je pense pas qu'un bricolage qconque (l'histoire du calcul de la clé à partir du hashage d'une autre clef qui ne vous parait pas bonne, c'est pas sain je pense, mais surtout, ce qui me fait tiquer le plus, c'est que vous vouliez faire le boulot du SGBDR pour la gestion/propagation des clés primaires/clés étrangères. Et vouloir le faire dans le sens clé étrangère -> clé primaire c'est un non sens, sémantiquement parlant) vous sauve la mise, dans votre situation
Message édité par Zzozo le 10-02-2012 à 19:34:20 --------------- « Ce qui ne vous tue pas vous rend plus fort » F. Nietzsche | « Vise_ la Lune. Si tu rates, au pire, t'es dans la merde » Un poète disparu dans le cercle |