Traitement des structures de données définies par l'utilisateur

Question

Est-ce que quelqu'un a des recommandations pour traiter les structures de données définies par l'utilisateur? c'est-à-dire que vos utilisateurs doivent être en mesure de définir des champs supplémentaires, et parfois des tables, à associer aux entités «fixes» de votre système. Je semble toujours avoir la malchance de finir par travailler sur des projets où c'est une composante majeure. Normalement, la solution finit par être des tables SQL générées dynamiquement, avec une génération SQL terrifiante collée sur les bords de l'ORM pour charger et sauvegarder les données dynamiques.

Il doit y avoir une meilleure façon de traiter cela, si vous avez abordé ce genre de chose auparavant, comment avez-vous réussi à faire fonctionner la partie dynamique de votre modèle avec un ORM? Est-il assez courant de générer des tableaux à la volée pour stocker les données, ou est-il préférable d'utiliser quelque chose comme une grande table de nom/valeur? Du point de vue des performances, les types de projets auxquels je pense ne sont pas très exigeants en termes de vitesse d'insertion/mise à jour, mais ils doivent être réactifs lors de requêtes et de rapports sur de gros volumes de données (notamment filtrage et agrégation les champs dynamiques).

Answer 1

Je ne sais pas ce que ORM est mais je pense que je comprends ce que vous demandez.

Pour les données étendues client dans des systèmes comme cette application, j'ai stocké les données dans un champ Xml dans la base de données et dans le magasin d'objets côté client en tant que XmlDocuments. Les champs Xml dans le serveur SQL sont facilement interrogés et mes classes d'objets enveloppent les données Xml personnalisées.