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

[Régis Houssin]

je reviens vite fait sur ce sujet
j'ai bien compris que pour les données d'un objet il est préférable de
créer autant de champs que de paramètres (quoi que c'est discutable pour
des paramètres sans contraintes ni index avec ce que je propose en
dessous... on se rapproche du nosql !)

en ce qui concerne les hooks par exemple, en ce moment je stock les
paramètres dans une constante en sérialisé.

est-ce qu'il serait préférable de les stocker en json ?
(json_encode/json_decode)

après divers tests il s'avère que le format json est moins gourmand en
caractères (et compatible ajax/jquery nativement... on rapproche encore
du nosql !) ;-))



Le 27/02/12 23:49, Laurent Destailleur (eldy) a écrit :
> 
> Le 27/02/2012 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";}
> 
> Pour ce qui est de changer le modele physique pour mettre tous les
> champs en 1, je ne suis pas d'accord.
> Si il faut stocker 500 propriétés indépendante et propre à un élément,
> il faut 500 champ dans la table de l'élément. Ce n'est pas un problème.
> Ce que tu compte faire, c'est déporter le modele physique d'organisation
> des données (des colonnes d'une table) dans un modèle de fichier plat (1
> seule colonne qui contient un seul champ tres long avec un séparateur
> pour séparé ce qui devrait etre des colonnes). Cela affranchi d'ajouter
> des colonnes mais il faudra de toute facon modifier le code pour gerer
> ces nouveaux champs. Donc modifier du code pour modifier du code autant
> le faire proprement.
> La base de donnée ne sert plus a rien dans ce cas. Autant mettre une
> table avec un seul champ et toutes les infos en serialisé.
> Dans ce modele, il faut dire adieu aux performances (plus moyen
> d'eploiter les index), a la recherche multicritere, a l'ajout futur
> d'intégrité, a l'evolutivité, aux possibilité d'import, etc...
> On peut ajouter un champ unique pour les modules externes qui en font ce
> qu'il veulent et stocke plusieurs info dedans mais si c'est pour des
> fonctions du core de dolibarr, cela doit etre dans des champs
> explicites, meme si il faut 500 champs. Il faut respecter ce qu'on
> appelle les "formes normales" du MPD au sein du core, meme si il est
> vraiu que les exemple données sont des données "défaut" de l'objet et
> non définitive. Mais dans ce cas, soit on crée un sous tables des
> valeurs defaut clé-valeur (on casse la forme normale 1-1), je préfère
> qu'on garde en table.
> 
> 
>>
>>
>> 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é.
> 
> un php différent interprete différemment d'un autre php car le serialize
> du php 1 va utilser un truc style json (a:2:[s:") un format décidé par
> la fonction nsysteme et celui du php2 dans une version plus ancienne va
> utiliser autre chose par exemple du base 64 ou encore une fonction
> systeme de l'OS. Ou encore les options du php.ini influence aussi le
> stockage comme l'option " *unserialize_callback_func". *Mais il y a
> aussi des options de compilation du php qui influe.
> Ceci explique qu'il faut utiliser sa propre fonction de serialization et
> non une fonction interne si on serialize pour stocker en base plutot que
> de se limiter a sa fonction de passage de paramètre entre services ou
> via fichier. Il vaut mieux que la serialisation soit sous le controle de
> l'applicatif.
> 
>>
>>
>> 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,
> 
> -- 
> Eldy (Laurent Destailleur).
> ---------------------------------------------------------------
> EMail: address@hidden
> Web: http://www.destailleur.fr
> 
> Dolibarr (Project leader): http://www.dolibarr.org
> To make a donation for Dolibarr project via Paypal: address@hidden
> AWStats (Author) : http://awstats.sourceforge.net
> To make a donation for AWStats project via Paypal: address@hidden
> AWBot (Author) : http://awbot.sourceforge.net
> CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
> 
> 
> 
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

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