/* 
[PHGD_ACXI]
    aucune donnée non numérique dans le champ PHGD_ACXI_PharmacodeNum dans les pharma N1 et N2
        recommendation => changement du type du champ
        impact en db:
            dbo.aps_PHGD_ACXI_1_1
            dbo.aps_PHGD_ACXI_2_1
            dbo.aps_PHGD_ACXI_3
            atl.BusinessCheck2

[PHGD_ACSC]
    aucune donnée non numérique dans le champ PHGD_ACXI_PharmacodeNum dans les pharma N1 et N2
        recommendation => changement du type du champ
        impact en db:
            dbo.aps_DWT_Item_Search_Generate_1_3
            dbo.aps_PH_Prescription_Line_5
            dbo.aps_PH_Prescription_Line_5_3
            dbo.aps_PH_Search_Item_1_1
            dbo.aps_PH_Search_Item_1_2
            dbo.aps_PH_Search_Item_1_3
            dbo.aps_PH_Search_Item_1_5
            dbo.aps_PHGD_SC_3
            atl.BusinessCheck2

Question:
    * le mail en pièce jointe dans la us parle d'un autre spike, est-ce que c'est relevant ?
    * Est-ce que l'ajout d'une FK vers item.PH_item_GUID ne serait pas plus judicieux ?
        Dans le mail en pièce joint, Gilles propose:
            Add column Item_id and delete column Pharmacodenum
    * item_key.ITK_key est de type [dbo].[Normal_name_field], qui est un varchar(30), il n'y a donc pas de pharmacode au format entier en db


Retour de la présentation au team:
    définir des scénarios et évaluer avec Roger Gruetter les cas.
    Il faut éviter d'utiliser les phcode pour faire les liaisons.
    Problèmes si les subsidiaries rentrent en jeux, duplication des résultats ?

    voir avec les devs si les problèmes de perfs sont génant pour les addresser, plutot que de revoir la structure.
  
Scénarios:  
     !!!! dbo.item et dbo.ph_item sont subsidiarisées via dbo.item_key !!!
     Un lien entre dbo.ph_item ou dbo.item et les tables phgd_xxxx crèe donc des doublons causé par les subs en centrale.
    
    Adding a "pharmacode" column in dbo.ph_item
        + simplify the link
        + as this is related to the pharmindex data only, does not implicate the subsidiaries.
          
        - could cause issues because dbo.ph_item is subsidiarized and multiple rows with the same pharmacode would exists in the centrals.
        - We duplicate the pharmacode. The "official" one is in the table dbo.item_key
        - We need to implement logic in triggers to maintain the satellite tables when the item_key value change / is created
        - The pharmacode is not a value that is fixed in time. It can be re-used, and makes a bad key for joints as it might represent different articles over a time period.
    
    Adding a FK to ph_item in both table
        this brings the same advantages and questions as the pharmacode, but with a stable relation that will not change in the time
        + simplify the link
        - could cause issues because dbo.ph_item is subsidiarized and multiple rows with the same pharmacode would exists in the centrals.

voir avec Roland Berger pour ces question
ou alors avec le team de Claude Castella

*/