En fait, je trouve ça pas mal pour une question de performance.
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
<AUGURIA.jpg>
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