Re: [Dolibarr-foundation-board] Lien vers table llx_bank

[Régis Houssin]

j'en remet une couche ;-)
vu qu'on utilise la même table pour les prospects, clients et
fournisseurs (voir autres avec les canvas), ce type de champs fourre
tout en sérialisé permettrai de stocker des données pour chaque type de
tiers, car un champ ne peut pas permettre de différencier un client d'un
fournisseur, alors qu'ici on peut stocker une valeur différente pour un
même paramètre si c'est un client ET/OU un fournisseur ou autre.


Le 27/02/12 15:15, Régis Houssin a écrit :
> par exemple on pourrait stocker tout les extra paramètres d'un objet,
> exemple :
> 
> le modèle de document, le compte bancaire à afficher sur le document, etc..
> ainsi on pourrais rajouter des paramètres sans à chaque fois créer un
> champ spécifique...
> 
> de plus un array:
> 
> array('model_pdf' => 'einstein', 'fk_account' => '1')
> 
> donne :
> 
> a:2:{s:9:"model_pdf";s:8:"einstein";s:10:"fk_account";s:1:"1";}
> 
> 
> c'est pour ça que je ne vois pas comment un php différent pourrait
> interpréter différemment !
> c'est juste le tableau (array) qui a été linéarisé.
> 
> 
> 
> Le 27/02/12 11:46, Régis Houssin a écrit :
>> quand on regarde un array sérialisé je ne vois pas trop ce qu'un
>> changement d'algo pourrait interféré, c'est juste une succession de type
>> et le nombre de caractères !
>>
>> beaucoup d'applications utilisent la sérialisation.
>>
>>
>> Le 27/02/12 10:49, Laurent Destailleur (eldy) a écrit :
>>> Hum, je vois pas trop ou tu veux en venir.
>>> Les données propres à une table x doivent rester dans la table x.
>>> Et pour les données transverses de config, il y a la table llx_const
>>>
>>>
>>> Note qu'il faut faire sauter l'utilisation de serialize pour stocker les
>>> données. serialize est une fonction systeme qui ne devrait etre utilisé
>>> qu'en interne au sein d'un traitement temporaire (pour passer des param
>>> par exemples ou stocker une info en cache) mais jamais en stockage base.
>>> La raison est que le résultat d'un serialize dépend de ton os et ta
>>> config system, voire version de php. En le stockant en base, tu rend les
>>> fonction de backup et restore ko des que tu change de version de php ou
>>> de systeme (potentiellement, meme si rare car l'algo de serialization
>>> change rarement).
>>>
>>> Il faut les remplacer, des qu'on stocke en base par un
>>> dol_serialize
>>> dol_unserialize
>>>
>>> et dedans, utiliser plutot un explode et join pour transfomer un tableau
>>> en chaine. L'applicatif doit avoir la maitrise du contenu de ces bases
>>> et ne pas dépendre d'une configuration ou environnement  systeme.
>>>
>>>
>>>
>>> Le 27/02/2012 10:28, Régis Houssin a écrit :
>>>> sinon j'avais pensé au départ ajouter un champ "options" ou "parameters"
>>>> où l'on pourrait stocker des couples "clé=>valeur" en sérialisé pour
>>>> tous les paramètres qui n'ont pas besoins de contraintes ou d'index. Je
>>>> pourrais modifier en ce sens ?
>>>>
>>>> Le 27/02/12 10:22, Laurent Destailleur (eldy) a écrit :
>>>>> OK. Dans ce cas, il s'agit d'une info d"aide à la saisie" et non
>>>>> d"intégrité" de donnée.
>>>>> Aussi, il ne faut pas mettre de clé étrangère.
>>>>> En effet, on doit pouvoir avoir dans ce champ un compte bancaire qui
>>>>> plus tard pourra etre supprimé, car comme c'est juste une info pour
>>>>> proposer le virement, si le compte bancaire est supprimé ce n'est pas
>>>>> grave, il ne sera plus trouvé et on affichera à nouveau le compte par
>>>>> défaut. Cela évite d'avoir à gerer des dépendances trop fortes entre
>>>>> table. Quand le lien est purement informatif (c'est le cas ici, il
>>>>> propose le compte bancaire par défaut sans empecher de finallement
>>>>> saisir le paiement sur un autre), il faut éviter les clés étrangères.
>>>>> Seul l'index doit rester.
>>>>>
>>>>>
>>>>>
>>>>> Le 27/02/2012 10:13, Régis Houssin a écrit :
>>>>>> afin de définir un compte bancaire différent que celui défini par
>>>>>> défaut
>>>>>> pour afficher le rib dans le document lors d'un virement par exemple,
>>>>>> certaines sociétés ont ce besoin car elles peuvent utiliser un compte
>>>>>> bancaire différent suivant le client.
>>>>>>
>>>>>>
>>>>>> Le 27/02/12 10:09, Laurent Destailleur (eldy) a écrit :
>>>>>>> Salut Regis.
>>>>>>>
>>>>>>> A quoi sert le nouveau lien des elements vers la table llx_bank ?
>>>>>>>
>>>>>> Cordialement,
>>>> Cordialement,
>>>
>>
>> Cordialement,
> 
> Cordialement,

Cordialement,
-- 
Régis Houssin
---------------------------------------------------------
Cap-Networks
Cidex 1130
34, route de Gigny
71240 MARNAY
FRANCE
VoIP: +33 1 83 62 40 03
GSM: +33 6 33 02 07 97
Web: http://www.cap-networks.com/
Email: address@hidden

Dolibarr developer: address@hidden
Web Portal: http://www.dolibarr.fr/
SaaS offers: http://www.dolibox.fr/
Shop: http://www.dolistore.com/
Development platform: https://doliforge.org/
---------------------------------------------------------