Utiliser les données avec une structure variable

Question

Imaginez un système qui fonctionne avec des données, structure qui évolue avec le temps. Dites, par exemple, aujourd'hui votre objet utilisateur contient Name: String et Email: String, mais demain vous devez ajouter Age: Integer et Address qui se compose de Country, Code postal, etc. Ensuite, vous pouvez créer un nouveau champ User.Contacts et déplacez le courrier électronique et l'adresse vers ce champ, comme le refactoring. Et cela devrait être fait pendant l'exécution, sans codage et redéploiement, car cela sera fait par les clients ou les administrateurs, pas par les développeurs. Quelles approches et quels outils envisageriez-vous pour stocker ces données? Sera-t-il une table distincte pour chaque classe d'objets et table changeante chaque fois que la structure est modifiée, ou une relation un-à-plusieurs entre l'objet et ses valeurs de propriété (comme la table StringProperties avec les champs ObjectID, PropertyID, StringValue); ou une grande table pour tous les objets (avec les champs génériques StringField1, NumericField2, etc)

Comment feriez-vous fonctionner l'indexation? Envisagez-vous d'utiliser des outils moins courants comme CouchDB? Y a-t-il d'autres outils que je devrais connaître?

Existe-t-il des exemples d'application ayant une idée similaire - permettant aux utilisateurs de définir et d'augmenter leurs propres structures de données?

EDIT: Je ne m'attends pas à ce que quelqu'un résout tout mon problème de conception. Des idées approximatives ou des liens vers des outils comme CouchDB ou Prevayler sont plus que bienvenus. Tous les liens d'article sont les bienvenus aussi.

Answer 1

Je pense que cela dépendra en grande partie sur la longévité des données et la langue que vous êtes.

Pour une structure de courte durée, dans un langage dynamique, je serais tenté d'aller à faible front et utilisez un Hash of Lists. À l'autre extrémité de l'échelle - quelque chose que vous devez persister et que vous voulez vraiment une base de données relationnelle, alors je passerais probablement à une architecture plus modulaire, où le code client prend en charge tout le cycle de vie des données - jusqu'à et y compris les instructions create table, le marshalling et unmarshalling, et l'interrogation des données. Pour le problème de marshalling/unmarshalling/query, il existe une autre branche de la route qui utilise peut-être un outil ORM ou une approche SQL plus basse technologie/raw. De toute façon, vous auriez besoin d'une sorte d'approche par étapes qui fait partie de la conception modulaire.

Bien sûr, comment vous organisez votre structure de données quand il est en mémoire pourrait être une simple carte de listes, ou une approche plus sûre de type, comme trouvée avec le "pattern" d'Eclipse IAdaptable. Sinon, vous êtes dans le domaine des outils comme Prevayler, qui sont plus évolués pour la sérialisation des outils disque que les SGBDR. Sur une note de côté, vous pourriez faire beaucoup pire que CouchDB.

Answer 2

Si l'exigence est que vous avez besoin la possibilité de créer des paires nom-valeur au hasard, puis sous une forme ou une autre, vous vous retrouverez avec une ou plusieurs tables de paires nom-valeur:

ID  USER_ID PROPERTY_NAME   PROPERTY_VALUE 
--------------------------------------------------------------- 
1  1   Name     Chris 
2  1   Occupation   Developer 
3  2   Name     Joe 
4  2   Hair Color   Brown 

... et ainsi de suite. Bien sûr, ces tables de nom-valeur deviennent folles avec le temps, donc l'indexation et le partitionnement sont importants; Dans la mesure où vous pouvez classer les types de propriété dans des tables distinctes tout en conservant la flexibilité dont vous avez besoin, vous pourrez conserver la taille de la table sous un contrôle relatif.J'ai travaillé sur des projets qui utilisaient cette approche, avec des tailles de table s'étendant sur des dizaines de millions de lignes (sur SQL Server & Oracle - je ne peux pas garantir personnellement pour les autres) sans problème. Je ne suis pas un administrateur de base de données, mais en termes d'indexation, je crois comprendre que vous aurez besoin d'un index clusterisé pour garder les enregistrements associés relativement proches sur le disque, et dans mon exemple, vous voudrez probablement un non-index. -Un index non-unique sur USER_ID, puisque vous seriez directement interrogé, mais au-delà, je n'ai pas de recommandations spécifiques - à part peut-être lire l'excellent livre de Stephane Faroult: The Art of SQL, qui offre beaucoup plus d'informations que je pourrais jamais sur ce sujet complexe. Bonne chance!

Answer 3

Si vous voulez que l'utilisateur final/l'administrateur apporte les modifications, vous ne pouvez vraiment pas avoir accès au schéma et ajouter/supprimer des relations et des tables etc, cassera quelque chose.

Auparavant, j'ai utilisé un schéma générique basé sur XML pour stocker des informations comme celle-ci. Vous vous retrouvez avec quelque chose comme ça (psydo-xml):

< données >
<Nom> Quelque chose </Nom >
< date de naissance> 2008-01-01 </date de naissance >
<Adresse>
<Rue> 1a Foo St </Rue >
...
</Adresse >
</données >

Pour pouvoir rendre ce HTML (ou quoi que ce soit d'autre) un fichier de métadonnées a été utilisé pour indiquer ce que chaque type était, (à savoir DOB = date, Adresse/Rue = chaîne) et le bon rendu utilisé pour rendre la sortie à l'écran dans la même apparence heirachal que le XML

Vous ne savez pas si cela est adapté à vos besoins, parce que c'est si générique, vous avoir une capacité limitée pour spécifier la disposition et ce genre de choses. L'approche ci-dessus a été utilisée pour le rendu des fichiers de configuration génériques.