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

[Laurent Destailleur (eldy)]

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