Bonjour à tous, Je suis sans doute le seul à utiliser ça en prod' et ce n'est pas grave, je m'adapterais ;-) J'ai utilisé ce mécanisme de création de table parce que ça me permettait de me brancher sur la gestion existante des attributs. De plus, celà permet des champs typés, ce que me permet pas la table rowid/optid/valeur, où valeur a forcément un type unique, ce qui rend les tri/classements/aggrégations plus compliqués. Comme tout choix, ce n'est qu'un compromis qui crée des inconvénients.
Encore une fois, je vous remercie d'avoir passé du temps à regarder ma proposition, et suis plus qu'heureux que vous vouliez l'intégrer. Sous quelque forme ce ce soit. Comme vous avez une vision d'ensemble plus large, je suis par essence d'accord avec vos choix ;-) Aujourd'hui, c'est le module d'export qui est la source de toute mes attentions. Cordialement, Tibo Régis Houssin a écrit : > En fait je finalise le schéma des bases et je vous l'envoi pour validation. > Ce schéma permettra de gérer les options des membres, mais aussi pourra > gérer les options des autres modules/fiches et aussi les déclinaisons de > produit. > > > > Le 08/11/09 03:03, « Laurent Destailleur (Eldy) » <[email protected]> a > écrit : > > >> Oui, ce serait préférable d'utiliser des enregistrements plutot que >> modifier le format des tables. >> >> Par contre, mieux vaut attendre après la release 2.7 car ce sont des >> modifs lourdes. >> _______________________________________________ Dolibarr-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dolibarr-dev
