Système de type personnalisé dans une base de données relationnelle

Question

Pour une application, nous capturons certaines données de formulaire. L'utilisateur peut inclure les différentes sections à volonté.

Le type de données qui doit être capturé dans chaque section est personnalisé par section. Parfois, ce sont de simples dictionnaires de paires clé-valeur. Parfois, ils contiennent des sous-composants avec des relations un-à-plusieurs ou plusieurs-à-plusieurs. Bien que le nombre de sections puisse augmenter, pour chaque section un schéma serait connu. Dans le passé, les sections de formulaire étaient fixes et nous pouvions simplement coder en dur les structures de table pour chaque section. Nous n'avons pas de façon générique d'implémenter des sections - c'est un nouvel accès aux données et des tables pour chaque nouvelle section. MAIS, une nouvelle exigence indique que l'utilisateur devrait être capable de concevoir ses propres sections. Pour éviter une manipulation dynamique des tables de base de données, nous souhaitons migrer vers un schéma d'ordre supérieur pouvant exprimer ces sections dans les données.

Si les données étaient simplement des paires valeur/clé de champs à valeur unique, cela pourrait être implémenté avec une table Sections et une table SectionFields. Mais en raison de la possibilité d'imbrication à travers des champs à valeurs multiples et des champs de type complexe, je crois que nous devrions aborder cela comme un système de type rudimentaire. Je ne pense pas qu'il a besoin d'héritage. Plutôt que de tout réinventer, je suppose que le travail a été fait dans les schémas pour les systèmes de types efficaces stockés dans la base de données. Des pensées/conseils?

Merci.

Answer 1

Jason,

Je ne suis pas sûr de comprendre votre question. Voici un résumé de ce que j'ai lu en le relisant:

Vous capturez des données de formulaire pour une application. Vos exigences ont été modifiées pour autoriser les sections définies par l'utilisateur. C'est un casse-tête pour vous parce que dans une base de données relationnelle, vous devez modifier dynamiquement les tables pour répondre à cette nouvelle exigence.

Cela peut être le cas lorsque vous utilisez le mauvais outil pour le travail. Les bases de données relationnelles sont idéales pour stocker et récupérer des données avec des relations bien établies, mais elles sont plutôt terribles lorsque vous avez des relations vaguement couplées ou indéfinies dans les données. Vous pourriez trouver que vous êtes mieux avec une technologie comme XML, qui gère beaucoup mieux le stockage pour les ensembles de données faiblement couplés.

Désolé, ce n'est pas ce que vous cherchiez. Ceci est mon premier post de réponse sur StackOverflow, donc je suis toujours en train de comprendre.

Bonne chance,

Michael

Answer 2

Si l'utilisateur est autorisé à créer ses propres types de données, la base de données qui les stocke n'est plus une base de données relationnelle. Tenter de stocker ces données de manière traditionnelle va être le chaos.

Vous devez envisager de stocker ces données sous forme de fragments XML. Si vous pouvez créer un schéma XML pouvant prendre en charge les sélections des utilisateurs et si votre base de données prend en charge un type de données XML (comme les nouvelles versions de SQL Server), vous pouvez toujours effectuer des requêtes utiles sur les données.