Bonjour,
 
J'ai un script, initialement fait par un collègue, à entretenir qui ne me convainc pas vraiment mais je ne vois pas comment le corriger:
 
- Nous avons une table A dont les colonnes sont : action | personne (personne est le prénom + nom). Pas de contrainte UNIQUE sur les champs individuels mais on peut en mettre une sur le couplet. Je voudrais éviter de devoir modifier cette table car elle est utilisée par plusieurs process écrits par d'autres personnes.
- Nous devons produire une table B: PERSONNE_ID | action . PERSONNE_ID est un ID représentant de manière inequivoque une personnne (relation 1:1) et ayant un format précis dicté par le business (champs alpha-numerique de taille donnée).
 
Le challenge:
- Nous recevons des CSVs avec les couplets "action | personne" de la part d'un client et devons dynamiquement générer les PERSONNE_ID dans le bon format pour pouvoir les traiter.  
 
Mon collègue a implémenté un curseur qui insère les couplets CSV et pour chaque entrée, contrôle si la personne a déjà un PERSONNE_ID dans une table C "PERSONNE_ID | personne". Si oui, on l'utilise; Si non, on en génère un nouveau, on l'insère dans C et on l'utilise pour B.
 
L'histoire c'est que ça me derange d'utiliser un curseur pour ça et qu'on balance des flopées de requêtes pour rien. ça marche cependant assez bien parce qu'on a peu de données dans ces tables.
 
Mon idée:
Utiliser quelque chose du style INSERT INTO B ("l'action", ID_GENERATING_FUNCTION("id)); où "ID_GENERATING_FUNCTION" s'occuperait de l'entretient de C et retournerait les bonnes valeurs.
 
Le soucis:
- Une user defined function ne peut pas modifier une table
- Une procédure ne peut pas être appelée de cette manière dans une requête
 
 
Question: Avez vous une idée de comment on pourrait s'y prendre?
 
Merci d'avance!

Fais une table séparée PERSONNE, avec ID, Nom, Prenom, etc...
Utilise l'ID dans ta table A et B (quoi que tu n'auras probablement plus besoin que d'une des deux).
 
Si d'autres appli ont besoin des tables A et B tu peux toujours en faire des vues.
 
Comme ca tu n'as qu'une seule action pour ajouter une nouvelle personne et puis une seule insertion dans la table A et/ou B.

Avec un trigger (qui génèrerait l'ID) sur INSERT, ça le ferait pas?

Ok je vais regarder
J'aime bien la méthode de Oliii, faut juste voir le fait de passer à cette vue pose pas trop de problèmes.
 
@rufo: On essaie d'éviter les triggers

Perso, je suis aussi contre les triggers, c'est pas moi qui va te jeter la pierre