Méthode conseillée pour une table "comment" dans une base de données relationnelle

Question

Supposons que vous souhaitiez créer une base de données pour une application Web. Cette base de données contient déjà plusieurs tables et vous devrez peut-être l'étendre dans le futur.

De plus, vous voulez que l'utilisateur final puisse commenter n'importe quel type d'objet dans la base de données.

Je voudrais trouver une solution pour cela serait assez générique afin que je ne devrais pas l'étendre chaque fois que j'ajoute une nouvelle table dans la base de données.

Je pensais que des éléments suivants:

Nom de la table: commentaire

colonnes:

• id: l'id d'un commentaire
• user_id: l'id du utilisateur faisant le commentaire
• nom_table_objet: onglet le où l'objet commenté est
• objet_id: ID de l'objet commenté dans la table nom_table_objet.
• texte: le texte
• Date: la date

Ce tableau résoudre sorte de mon problème, la seule chose qui me préoccupe est que l'aspect relationnel de celui-ci est assez faible (je ne peux pas faire object_id une clé étrangère par exemple). Aussi, si un jour j'ai besoin de renommer une table, je vais devoir changer toutes les entrées concernées dans la table des commentaires.

Que pensez-vous de cette solution? Y a-t-il un motif de conception qui pourrait m'aider?

Thanks.-

Answer 1

N'est-ce pas plus propre?

Table comment_set

• id

Table commentaire

• id
• comment_set_id -> clé étrangère à comment_set
• user_id
• Date
• texte

table existante foo

• ...
• comment_set_id -> clé étrangère à comment_set

de table existante bar

• ...
• comment_set_id -> clé étrangère à comment_set

Answer 2

Vous confondez des données et des métadonnées, qui ne sont pas le meilleur modèle de conception. Ils devraient être séparés.

Cependant, puisque les commentaires ne semblent pas très importants de toute façon, votre solution est OK. La pire chose que vous pouvez faire est de perdre des commentaires sur vos objets.

Certaines bases de données, notamment PostgreSQL, prennent en charge la clause COMMENT uniquement pour les cas de ce type.

Mise à jour:

Si vous voulez faire des commentaires sur les dossiers individuels dans chaque table, il est normal d'avoir une telle table.

object_table_name ne doit pas être modifié si vous renommez une table, car il s'agit de données et non de métadonnées.

Vous ne pouvez pas écrire une requête SQL native qui récupérera des commentaires pour l'enregistrement d'une table (inconnue au moment du développement de la requête), bien que vous puissiez créer les requêtes dynamiques pour le faire.

Dans ce cas, vous devrez synchroniser vos données et vos métadonnées (UPDATE la table de commentaires lorsque vous RENAME le tableau auquel elles se rapportent).Le premier est une instruction DML (modifie les données), le second est DDL (modifie les métadonnées).

Assurez-vous également que tous les PRIMARY KEYs ont les mêmes types (identiques à object_id).

Answer 3

En savoir plus sur EAV. Vous pouvez créer votre base de données entière comme ça. Mais alors ce sera l'enfer de travailler avec ces données. Pourquoi ne voulez-vous pas placer un attribut Comment pour chaque entité de base de données qui doit prendre en charge les commentaires? De cette façon, vous pouvez obtenir toutes les données dont vous avez besoin dans une seule requête, et de nombreux programmes GUI pour les bases de données vous fourniront un code complet en SQL, ce qui évitera les erreurs qui peuvent facilement se produire avec des chaînes. De cette façon, le code dépend fortement du code de procédure, ce qui n'est pas approprié pour les systèmes de base de données.

Answer 4

Vous pouvez énumérer les noms de table dans une table distincte, de sorte que les changements de noms n'affectent pas le système de manière majeure. Juste mettre à jour la table d'énumération. Bien que vous vous éloigniez de l'intégrité référentielle, je peux voir une autre façon d'accomplir ce que vous voulez.

Answer 5

Je préfère généralement conserver les commentaires avec les lignes auxquelles ils s'appliquent. En supposant que votre base de données stocke efficacement les champs VARCHAR vides, vous ne devriez pas payer de pénalité pour cela. Il n'y a vraiment rien à "étendre" lorsque vous implémentez cette approche, la maintenance du commentaire fait partie des requêtes que vous utilisez déjà pour mettre à jour les lignes.

Le seul avantage de l'approche de table à note unique est qu'elle permet des recherches aisées dans les notes pour différents types d'entrées de base de données.

Answer 6

En supposant MS SQL, et si le volume est relativement petit, comme vous semblez le suggérer, alors Extended Properties pourrait être utile d'explorer. Je les ai utilisés avec succès dans le passé et ils semblent être un dispositif permanent.