Salut,

Richelle Simon a écrit :
> Je reprends mon travail sur l'import de données.
>
> Suite à ce qu'avait dit Olivier Perron, j'ai donc finalement dégagé 3
> fonctionnalités lors de l'import :
>
> Soit on veut :
>       - ajouter à la suite
>       - remplacer purement et simplement (on vide donc la table avant)
>       - mettre à jour des enregistrement
>
> Le dernier ne pose aucun problème : on part du principe que l'id_adh est
> le même et c'est terminé.
>   
En effet
> Cependant pour les deux autres je me pose une question :
> des infos sur l'adhérant X sont présent dans plusieurs tables (adhérents
> et cotisations). Si on rajoute à la suite, on va laisser mySQL créer un
> nouvel id_adh pour cet adhérent. Donc on va perdre le lien entre
> adhérents et cotisations... Que faire? limiter la fonction ajouter à la
> table adhérant?
>   
Il est possible de récupérer le dernier ID attribué sous mysql depuis
php, je suppose donc que Pear::MDB2 et adodb permettent ce genre de
joyeuseté.
> Dans le même goût, est-ce lors d'un remplacement pur et simple, mySQL va
> accepter que je lui impose un id_adh puisqu'il est définit en
> "auto_increment" dans la table. Je sais que Access crie si on fait ça.
>   
Il me semble (de mémoire j'ai pas re-vérifié) que tu peux faire ça. Ceci
dit, je serai plus partant sur une ré-initialisation de l'auto_increment
(possible sous mysql, voir Pear::MDB2 ou adodb), et pour laisser la base
attribuer l'identifiant...
Cela ne me paraît guère gênant puisque les seules utilisations de l'ID
adhérent se font en interne dans les bases, tu peux alors utiliser le
dernier id attribué pour insérer les cotisations etc en fonction de l'id
adhérent originale.
> Qu'en est-il de mysql ou postgre??
>
> Merci de votre aide éclairée! 
>
> Cordialement, 
> Simon
>   
Just my two cents,
Johan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Galette-devel mailing list
Galette-devel@gna.org
https://mail.gna.org/listinfo/galette-devel

Répondre à