Je dois concevoir un modèle d'entité JPA pour hashtags dans mon application similaire à Instagram, Twitter et débordement de la pile. Mon application. Voici les points spécifiques de schéma que nos utilisations d'application
- Hashtag devrait être appartient à une question
- Est spécifique Hashtag utilisateur.
- Chaque utilisateur peut marquer leur question avec la même hashtag
À l'heure actuelle, j'ai deux modèles JPA pour le schéma ci-dessus
tableaux communs applicables pour les deux modèles
Table: questions
colonnes: id, question, description, etc.,
Table: les utilisateurs
colonnes: id, nom, rôle, groupe, etc.,
modèle 1
Tableau: question_hash_tags
colonnes: id, question_id, user_id, hashtag_text
modèle 2
Tableau: hashtags
colonnes: id, hastag_text
Tableau: user_hashtags
colonnes: user_id, hashtag_id, question_id
Modèle 1 aura chaque ligne même si hashtag est le même entre les utilisateurs.
Modèle 2 aura la ligne de hashtag unique et il est reffered entre les utilisateurs en utilisant user_hashtags.
J'attends un meilleur modèle et la norme au-delà de ces deux.
Note: Les questions sont consultables sur la base hashtags ainsi que les utilisateurs
Nous avons trois « choses » ici: Les utilisateurs, les questions et les hashtags. Il faut éviter le modèle n ° 1 dans votre exemple, principalement parce qu'il est pas flexible. Qu'est-ce qui se passe lorsque le propriétaire du produit décide par la suite d'ajouter une description aux balises? Qu'advient-il si le propriétaire du produit de la semaine prochaine veut un utilisateur de choisir uniquement les balises d'une piscine existante? Bien que vos besoins de domaine sont incomplètes et peu claires, une solution plus souple permet d'implémenter des fonctionnalités d'avenir sur le dessus de votre modèle sans grand refactoring. Cela dit, je considère certainement Hashtag d'être sa propre entité indépendante.
Dans votre deuxième modèle, la relation tertiaire représentée dans le tableau de USER_HASHTAGS semble prendre une option beaucoup à plusieurs entre utilisateurs et questions. En effet, si votre domaine exige que de nombreux utilisateurs peuvent créer la même question, je pense que le modèle n ° 2 serait la suite vos besoins. Plus probablement, votre exigence pourrait limiter explicitement la possibilité pour plus d'un utilisateur à l'auteur une seule question spécifique. Dans ce cas, ces contraintes devraient être placées dans le modèle. De plus, si un utilisateur décide de marquer une question avec 5 balises différentes, que l'on-à-plusieurs entre les utilisateurs et les questions seraient 5 fois affirmé dans votre table user_hashtags pour chaque balise. Une simple requête pour afficher des questions par écrit un utilisateur impliquerait l'utilisation DISTINCT qui devrait augmenter immédiatement la sonnette d'alarme au sujet de la conception.
En supposant un à plusieurs entre les utilisateurs et les questions, je retire la USER_ID de votre table « USER_HASHTAGS » et mis à la place du USER_ID dans la table des questions en tant que clé étrangère. Renommez ensuite votre table de USER_HASHTAGS à QUESTION_HASHTAGS. Cela le rend à la fois simple et performant parce que maintenant vous pouvez simplement interroger une seule table pour obtenir des questions rédigées par un USER_ID spécifique sans se joindre et en ajoutant qui-sait-comment-plusieurs doublons la base de données aurait besoin de filtrer Distinct. Aussi maintenant pris en charge est la possibilité où un utilisateur choisit de ne pas inclure un hashtag pour leur question (pas de clé étrangère en blanc).
REMARQUE:
Il y a plusieurs facteurs qui influencent la conception physique d'une base de données - non seulement les modèles d'accès « select », mais peut-être même la fréquence relative de chacun. Le rapport entre la base de données écrit se lit comme suit, ce qui peut être mis à jour et à quelle fréquence par rapport à d'autres mises à jour, etc., peuvent également influer sur la façon dont vous structurez vos tables à la fin. Donc, il n'y a pas de réponse « définitive », juste une réponse fondée sur quelques hypothèses et que les informations fournies dans votre question.