Décision de conception: ajout dynamique de données question

Question

Je dois donner aux utilisateurs la possibilité d'ajouter des métadonnées aux documents. Une autre façon d'indiquer cela est le fait que les utilisateurs doivent ajouter au moins 5 catégories à un document.

Fondamentalement, ce que je veux faire est d'ajouter dynamiquement des métadonnées (ou catégories) à un document sur une base ad hoc. Voici les options que j'ai pensé:

Option 1: Dois-je faire cela en créant dynamiquement de nouvelles colonnes de table dans la base de données?

Option 2: Dois-je définir 5 colonnes appelées attirbute1, attirbute2, attirbute3, attirbute4, attirbute5 puis utilisez seulement et leur montrer que si l'utilisateur a besoin des attributs.

Option 3: Dois-je créer une table de métadonnées qui garde la trace des colonnes et des données qui leur sont associées?

Selon vous, quel est le meilleur moyen d'y parvenir? Pouvez-vous penser à d'autres façons d'ajouter facilement cette fonctionnalité. Le problème est que la fonctionnalité doit être très générique.

Answer 1

Chaque document a un DocumentID unique.

il suffit d'ajouter une autre table qui a trois colonnes:

DocumentID 
MetaName 
MetaData

Ensuite, ils peuvent ajouter autant de morceaux de métadonnées à un document donné. Si tous leurs documents utilisent les mêmes méta-noms, il est trivial de rechercher les métadonnées.

-Adam

Answer 2

Toutes ces options sont réalisables, et il n'y a pas une réponse correcte. Vous devriez peser vos différentes options et choisir la meilleure solution pour votre situation.

Option 1: réalisable mais pouvant devenir incontrôlable à mesure que le nombre d'utilisateurs augmente. Peut également avoir un impact sur les coûts de stockage.

Option 2: Probablement la solution la plus rapide à mettre en œuvre mais la solution la moins robuste et un coût de maintenance plus élevé. Si vous devez passer à 6 colonnes, vous devrez ajouter une autre colonne, etc.

Option 3: La solution la plus robuste est probablement d'avoir une table de métadonnées qui capture cette information et ensuite de construire dynamiquement vos tables \ colonnes basé sur cette métadonnée. Cette solution prendra probablement le plus longtemps et coûtera le plus cher $$.

Answer 3

Cela ressemble beaucoup à l'étiquetage. Vous pouvez probablement modifier acts-as-taggable pour faire ce dont vous avez besoin.

Answer 4

J'irais certainement avec l'option 3: avoir une table appelée DocumentCategories, qui stocke la catégorie à laquelle appartient chaque document. Non seulement c'est «plus relationnel», mais cela aidera aussi si vos besoins changent: que se passe-t-il si vous décidez que vous voulez 6 catégories demain? De plus, cela vous donne plus d'options pour l'interrogation: et si vous voulez voir combien de fois chaque catégorie a été utilisée, ou pour sélectionner des documents par catégorie? Avec l'option 3, c'est juste une jointure, et c'est rapide et facile à écrire. Les options 1 et 2 rendent les choses simples comme ça très compliquées.

Answer 5

Je voudrais aller avec l'option 3.

changer Dynamiquement la structure de données deviendra très difficile à maintenir, et pourrait introduire des intéressants bugs.

Avoir un certain nombre de colonnes qui peuvent ou peuvent ne pas être nécessaires sera encore plus complexe becuase vous devez vérifier si chaque colonne est utilisée. De plus, vous serez toujours limité à 5 colonnes.

Option 3, mais est très flexible et permet la croissance. Juste avoir une clé étrangère se référant au document, une colonne pour le nom, et une colonne pour la valeur.

Answer 6

Je voudrais aller avec trois tables.

document (le document)

Catégorie (Les catégories définies)

DocumentCategory (Une table de liaison reliant les documents à des catégories)

Le seul inconvénient est que votre DBMS pourrait ne pas soutenir une bonne façon pour contraindre cette conception à exiger au moins cinq entrées dans DocumentCategories par document, mais vous pouvez l'appliquer au niveau de l'application.

Answer 7

Une chose que vous ne faites pas clair si le nombre et/ou le nom d'attributs est modifiable ou si elle est la même pour tous les documents. Cela modifierait quelque peu ma recommandation.

présumant que vous avez une poignée d'objet qui décrit de façon unique un document donné, je vous propose une table qui gère les méta-données. Si vous avez un nombre inconnu d'attributs et des noms inconnus de ces attributs, je recommande quelque chose comme ceci:

create table DocMetaData 
(
    DocumentHandle  varchar NOT NULL, 
    MetaDataName   varchar NOT NULL, 
    MetaDataText   varchar NOT NULL 
); 

Vous insérez dans cette table lorsque vous avez des méta-données en utilisant le nom qui est le plus approprié. S'il n'y a pas de ligne, il n'y a pas de méta-données. S'il y a des méta-données, vous avez clairement un nom pour ces méta-données, et les données elles-mêmes. Vous pouvez inclure la nullité sur les métadonnées même si vous en avez besoin, même si je devrais probablement en faire un texte vide (quelque chose comme default ''), plutôt que des valeurs nulles parce que vous avez des comportements étranges (n'obtenez pas votre ligne!) sélectionnez une colonne et ce n'est pas là et vous n'avez pas demandé explicitement les lignes de valeur null. Rappelez-vous, cette conception n'épelle pas unique de sorte que vous avez l'optionalité, seulement stocker quand vous avez des données ...

Bien sûr, si tous les attributs de métadonnées possibles sont connus, vous pouvez simplement les épeler !

création de la table dynamique est une douleur ROYAL - Je ne le ferais pas ici.