61 lines
3.0 KiB
Transact-SQL
61 lines
3.0 KiB
Transact-SQL
/*
|
|
[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
|
|
|
|
*/ |