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

[Régis Houssin]

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,
-- 
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/
---------------------------------------------------------