Critère technique | A. 1 table (type,id_entite,attr,value) | B. Polymorphe typé (eav_text/int/…) | C. Par entité (objet/contact/document)
Lecture “fiche” (charger 10 attributs d’un ID) | ✅ Simple (WHERE type & id_entite) ; 1 index BTREE suffit | ✅ Idem (sur chaque table typée utilisée) | ✅ Idem (sur la table du type d’entité)
Recherche =, LIKE 'x%', ILIKE '%x%' | ✅ BTREE (égalité/préfixe) + GIN trigram partiel par type ; attention taille si global | ✅ Meilleur contrôle : trigram seulement sur eav_text ; tables plus petites | ✅ Trigram ciblé par entité + attribut ; très compact
Volume d’index | ⚠️ Gros si tu mets GIN/BTREE globaux ; mieux si partiels par type/attribut | ✅ Plus petit (les types non textuels n’ont pas le trigram) | ✅ Plus petit (index par table d’entité)
Insert/Update | ✅ 1 chemin d’écriture ; ⚠️ gros GIN = coût de maintenance | ✅ Écrit dans la table du type réel → moins d’index touchés | ✅ Écrit dans la table d’entité ; index compacts
Unicité “1 attr par entité” | ✅ UNIQUE(type,id_entite,attribut_id) simple | ✅ Idem par table typée | ✅ Idem par table d’entité
Intégrité vers l’entité | ⚠️ FK polymorphe non native (table entities ou triggers) | ⚠️ Même remarque | ✅ FK native par table (objet_id→objets)
Évolution : nouveau type d’entité | ✅ Ajout d’un type de plus (pas de schéma) | ✅ Idem | ⚠️ Nouvelle table (+ index)
Évolution : nouveau type de valeur | ⚠️ Tu stockes en text (ou ajoutes des colonnes) | ✅ Plug & play : nouvelle table eav_* | ✅ Soit tu restes “untyped text”, soit tu dupliques par type de valeur
Partitionnement Postgres | ✅ LIST sur type + HASH sur id_entite (reco) | ✅ LIST entity_type + HASH entity_id par table typée | ✅ Tables déjà séparées ; tu peux encore HASH par id
Stabilité des plans | ⚠️ “grosse” table hétérogène ; nécessite bons filtres/partitions | ✅ Tables plus homogènes ; plans plus stables | ✅ Très stables (tables dédiées)
Maintenance (VACUUM, stats) | ⚠️ Lourde sur une table de 1 Md ; mieux si partitionnée | ✅ Répartie : moins de bloat par table | ✅ Répartie par entité ; plus simple
Sécurité/droits | ✅ Simple (row level par type si besoin) | ✅ Par table typée | ✅ Très simple (droits par table d’entité)
Complexité côté appli | ✅ La plus simple (une table) | ⚠️ Moyen (router selon data_type) | ⚠️ Un peu plus de plomberie (3 tables)
Coût d’un GIN trigram global | ⚠️ Très élevé (taille + MAJ) | ✅ Limité à eav_text (moins de lignes) | ✅ Limité à la/les tables d’entité concernées
Recherche full-text “cross-tout” | ✅ Facile (une table) mais chère | ✅ Possible sur eav_text uniquement | ⚠️ Faut UNION/VIEW mais perf OK car plus petit