L'exigence est de stocker des pièces jointes pour différents types d'entité.
dire que nous avons 3 types d'entité société, département et employé. Chacun peut avoir plusieurs pièces jointes (documents).
Quelle est la meilleure façon de gérer cela?
Table de l'entreprise
table de service
Table des employés
Table d'atthantype
Table des pièces jointes
Avantages: je peux ajouter de nouveaux types d'entité facilement à l'avenir
Inconvénients: Dans ce cas, je ne peux pas avoir la relation clé étrangère maintenue entre entités et pièces jointes.
Table de l'entreprise
table de service
Table des employés
Table de compagniePartachements
Table de Deptatacchments
Tableau d'emploi de l'emploi
Avantages: Intégrité de clé étrangère
Inconvénients: Dans l'ordre, ajoutez une nouvelle entité, j'ai besoin d'avoir une nouvelle table d'attachement séparément.
Alors, quelle est la meilleure façon d'aller avec supposer que je puisse peut-être ajouter de nouvelles entités à l'avenir?
Merci pour votre réponse Guys.
Si je veux aller avec la solution 2, je vois que la création de nouvelles colonnes dans les pièces jointes Tableau plus facile au lieu de créer de nouvelles tables d'attachement pour chaque entité juste pour les cartographier?
quelque chose comme,
Table de l'entreprise
table de service
Table des employés
pièces jointes
Est-ce que je manque quelque chose ici?
5 Réponses :
Je vote pour la solution 2 parce que vous pouvez appliquer une intégrité référentielle de manière appropriée. De plus, vous pouvez facilement (si nécessaire) ajouter des champs pour des pièces jointes spéciales (par exemple, l'employée peut avoir un champ de bit «Personnalisé» ou similaire)
+1, Ajouter des champs pour des pièces jointes spéciales Les utilisateurs veulent éventuellement ceci.
Je vais certainement aller avec la solution n ° 2. Votre seul Pro pour la solution n ° 1 n'est pas vraiment un pro. Si vous ajoutez une nouvelle entité, vous devez nécessairement ajouter une nouvelle table pour cette entité et vous allez déjà ajouter ou modifier le code existant pour la gérer. Vous devriez être capable de faire des objets génériques qui gèrent le modèle afin que le code dupliqué ne pose aucun problème.
L'intégrité des données appliquée par FKS bat moins de temps pour la maintenance (en particulier un type de maintenance qui pourrait ne jamais être nécessaire) à chaque fois!
+1, la solution n ° 1 pourrait avoir des problèmes, que se passe-t-il lorsque vous avez la même valeur de clé de la société ID de la société / ID de dépôt / employé, comme si vous utilisez des valeurs d'identité / incrément automatique.
J'irais avec l'option 2.
quelque chose comme ceci:
J'aime cette solution, étant donné que la table des pièces jointes va avoir les mêmes propriétés pour toutes les entités.
@Puzzled Les champs qui ne sont pas communs ira à leurs tables spécialisées
Autres choses à prendre en compte:
allez-vous avoir besoin de faire rouler des pièces jointes? I.e. Les pièces jointes d'un employé sont associées à son département et à leur entreprise? S'il s'agit d'une requête fréquente une seule table d'attachement et une option de table d'appartements d'entité d'entité distincte et fortement indice peut donner une meilleure performance de la requête.
En outre, les pièces jointes vont-elles être nombreuses et suffisamment énormes que vous devez mettre ces table (s) sur un périphérique séparé ou un autre système de stockage (I.E. Pointeurs de système de fichiers)? La direction est un problème ainsi que des performances.
Nan. Les pièces jointes sont juste liées à leur entité correspondante et ne sont pas roulées. La table des pièces jointes stocke simplement le filepath / URL. Les fichiers réels sont stockés sur FileServer.
Bon alors, des tables séparées sont la voie à suivre. Je pense que vous avez une vision de l'Union de tous les noms ou chemins de fichier, afin que vous puissiez auditer les données. C'est-à-dire que quelqu'un a accidentellement supprimé le fichier, etc ... aussi si l'archivage est nécessaire, réfléchissez à la manière dont vous manipuleriez la zippation du contenu et de passer aux périphériques de différence (c'est-à-dire d'un disque à l'autre sur DVD, etc.)
J'espère que c'est explicite de soi.
Merci Damir. J'espère que cela doit être la solution optimale, si nous commençons à zéro. Mais malheureusement dans mon cas, les entités sont déjà utilisées, avec leurs propres identifiants en place.
Avez-vous examiné les bases de données NOSQL (I.E. COUCHDB) basées sur des documents?