Table/modèle dynamique dactylographié en Java EE?

Question

Généralement avec Java EE lorsque nous créons un modèle, nous définissons les champs et les types de champs par XML ou annotation avant la compilation. Y a-t-il un moyen de changer ceux en cours d'exécution? Ou mieux, est-il possible de créer un nouveau modèle basé sur l'entrée de l'utilisateur pendant l'exécution? Tels que le nombre de colonnes et les types de champs sont dynamiques (déterminé à l'exécution)?

L'aide est très appréciée. Je vous remercie.

J'ai ressenti le besoin de me clarifier.

1. Oui, je voulais dire la modélisation de base de données, quand on parle de modèle. Comme pour les cas d'utilisation, je veux fournir un moyen pour les utilisateurs de définir et de créer leurs propres tables. Une flexibilité infinie n'est pas requise. Cependant, un certain degré de liberté doit être là: par ex. les utilisateurs peuvent définir les champs nécessaires pour décrire leur produit.

Answer 1

J'ai travaillé sur un système où nous avions de telles installations. Pour rester efficace, nous générerions/modifierions la table dynamiquement pour le schéma client. Nous avions également besoin d'incorporer un méta-modèle (le modèle du modèle) pour traiter les informations dans les entités de façon dynamique. Avec les tables personnalisées, vous disposez d'une flexibilité totale, mais cela augmente également considérablement la complexité, notamment la mise à jour/la migration des données existantes. Voici une liste de choses que vous devrez prendre en considération:

• Que faire si le type d'une colonne change?
• Que faire si une colonne est ajoutée? Y a-t-il une valeur par défaut?
• Que faire si une colonne est supprimée? Puis-je supprimer les informations existantes?
• Comment gérer le changement de nom d'une colonne?
• Comment rendre les choses portables dans les bases de données?
• Comment le rendre efficace au niveau de la base de données (par exemple, des index)?
• Comment gérer une erreur humaine (par exemple, un utilisateur supprime une colonne puis change d'avis)?
• Comment gérer la migration (script, déploiement, etc.) lorsqu'une nouvelle version du système est installée sur le site du client?
• Comment avoir ceci en utilisant un ORM?

Option 2: Une alternative légère est d'ajouter quelques colonnes "de rechange" dans les tables d'affaires de différents types (par exemple: "USER_DATE_1", "USER_DATE_2", etc.) Je l'ai vu qu'une quelques fois. Cela fera hurler votre DBA et n'est pas vraiment considéré comme une bonne pratique, mais au moins peut faciliter certaines choses, par ex. (scripts de migration, intégration ORM).

Option 3: Une autre option consiste à stocker tout dans une table avec une propriété/des données de structure. Mais alors c'est vraiment un désastre pour la performance de la base de données. Tout ce qui n'est pas complètement trivial nécessitera beaucoup de jointures. Et le DBA criera encore plus.

Option 4: Il s'agit d'un mélange d'options 2 et 3. Les tables de base sont fixes, mais une table avec des propriétés/données peut être utilisée pour les étendre en quelque sorte. En résumé: réfléchissez-y à deux fois avant de passer à l'étape suivante. Cela peut être fait, mais a un impact significatif sur la conception et la maintenance de l'application.

Answer 2

Vous semblez vouloir modifier les objets et le schéma en fonction de l'entrée de l'utilisateur lors de l'exécution. Cela ressemble à une recette chaotique pour le désastre pour moi. Je ne l'ai jamais vu faire. J'ai vu des schémas généraux qui intègrent des relations de clés étrangères à des tables génériques de paires nom/valeur, mais elles tendent à devenir des abstractions infiniment flexibles qui ne peuvent être ni facilement comprises ni dégager de leurs propres moyens en matière de performance. Je parie que vos utilisateurs ne veulent vraiment pas une flexibilité infinie. Je vous préviens de ne pas prendre cette direction. Mieux vaut obtenir vos vrais cas d'utilisation directement.

Tout est possible, bien sûr. Mon expérience directe me dit que c'est une mauvaise idée que vos utilisateurs détestent si vous pouvez le retirer. Bonne chance.

Answer 3

Ceci est en quelque sorte possible en utilisant des techniques de méta-modélisation:

• tables pour la table/colonne/types au niveau de la base de données
• structures clé/valeur au niveau Java

Mais cette a des limitations évidentes (manque d'objets typés forts) et peut à mon humble avis rapidement devenir très compliqué (même pas sûr de savoir comment traiter avec les relations). Je n'utiliserais pas cette approche pour définir des objets de domaine entièrement, mais seulement pour étendre ceux existants (produits, articles, etc.).

Si je me souviens bien, c'est ce que certaines solutions de commerce électronique (par exemple BroadVision) faisaient.

Answer 4

Je pense avoir trouvé une bonne réponse moi-même. Ces nouvelles bases de données no-sql (hbase, cassandra) semblent être exactement ce que je cherchais. Merci à tous pour vos réponses.