faire un système de table horizontale et très coûteux en terme de requête et ne mont pas en charge.
Par contre, rien n'empêche de n'afficher des attributs que pour une famille de produit, quitte a avoir des champs vides.
Cyrille
 Cyrille de Lambert |
|
| address@hidden 9, rue Alfred Kastler BP 50752 44307 NANTES CEDEX 3 |
Tél
: +33 (0) 2
51 13 50 12 Mobile :+33 (0) 6 29 41 81 22 Fax : +33 (0) 2 51 13 52 88 http://www.auguria.net |
Le 18/06/2011 10:36, Régis Houssin a écrit :
ca va être ingérable, imagine un catalogue avec 10000 produit composé 50 familles de produits dont chaque famille à des types d'attributs différents, nous allons avoir une ribambelle de champs inutiles en fonction des familles dans les tables !! Le 18/06/11 10:32, Laurent Destailleur a écrit :Follow-up Comment #3, task #5226 (project dolibarr): Changement de strategie pour les champs personnalisés: Pour chaque table (llx_societe, llx_product) on crée un table d'attributs suplémentaire (llx_societe_extra, llx_product_extra) avec un lien par l'id sur la table principale. L'ajout d'un attribut a pour effet d'ajouter une colonne dans cette table. L'ajout de colonne et le scan des colonne existantes se fait grace aux methode de l'objet db. Ainsi on a un classement horizontal des attributs, sans compromettre les table principales. Ce qui permettra les fonctions d'import, export et facilite le dev egalement. _______________________________________________________ Reply to this item at: <http://savannah.nongnu.org/task/?5226> _______________________________________________ Message sent via/by Savannah http://savannah.nongnu.org/Cordialement,_______________________________________________ Dolibarr-dev mailing list address@hidden https://lists.nongnu.org/mailman/listinfo/dolibarr-dev