Conception de bases de données relationnelles - clés de substitution vs clés naturelles dans le contexte de la vitesse de requête, de l'ORM et du développement d'applications

dapper database-design orm relational-database sql

Question

Supposons que je dispose d'un ensemble d'entités «modèles» et d'un ensemble de niveaux de difficulté. Chaque modèle a un certain pourcentage de réussite pour un jour donné sur un niveau de difficulté donné.

Une entité modèle a un nom, unique et immuable en toutes circonstances, ce qui en fait une clé primaire naturelle. Un niveau de difficulté est décrit par son nom uniquement (facile, normal, etc.). Les niveaux de difficulté sont très, très peu susceptibles de changer, même s'il est possible d'en ajouter un nouveau. Un enregistrement de taux de réussite est uniquement identifié par le modèle auquel il se rapporte, le niveau de difficulté et la date.

Voici la conception de base de données la plus triviale pour ce scénario: db design avec des clés naturelles

Dans cette conception, «name» est la clé primaire de la table «models» et est représentée par un champ VARCHAR (20). De même, un champ 'name' de VARCHAR (20) est la clé primaire de la table 'difficultés_levels' (une table de consultation). Dans la table 'success_rates', 'model_name' est une clé étrangère référençant le champ 'name' dans la table 'model', et 'difficulté_level' une clé étrangère faisant référence au champ 'name' de la table 'difficulté_levels'. Les champs 'model_name', 'difficulté_level' et 'date' constituent une clé primaire composite pour la table 'success_rates'.

Les requêtes les plus utilisées seraient:

  • obtenir tous les taux de réussite pour un certain modèle, niveau de difficulté et période

  • obtenir les modèles les plus / les moins réussis pour une certaine période et niveau de difficulté.

Maintenant, ma question est la suivante: dois-je ajouter des clés primaires de substitution aux tables 'models' et 'difficulté_levels'? Je suppose que le stockage des valeurs int par opposition aux valeurs varchar dans les champs de clé étrangère de 'success_rates' prend moins de place, et peut-être que les requêtes seront plus rapides (juste ma conjecture, pas sûre de cela)?

Le problème que je vois avec les clés de substitution est qu’elles n’ont aucune pertinence pour la logique métier elle-même. Je compte utiliser un mini-ORM (probablement Dapper), et sans les clés de substitution, je peux opérer sur des classes qui représentent très clairement les entités avec lesquelles je travaille. Maintenant, si j'ajoute des clés de substitution, je vais devoir ajouter des propriétés "Id" à mes classes, et je suis vraiment contre l'ajout d'une telle implémentation à une classe pouvant être utilisée n'importe où dans l'application. connexion avec un stockage de base de données. Je pourrais ajouter des classes de stockage proxy avec une propriété Id, mais cela ajoute un autre niveau de complexité. Plus le fait que la propriété "Id" ne soit en lecture seule (l'ORM peut donc définir les identifiants après avoir enregistré l'entité dans la base de données) signifie qu'il est possible de la définir accidentellement sur une valeur aléatoire / non valide.

Je ne connais pas très bien les ORM et je n'ai aucune connaissance de Dapper, alors corrigez-moi si je me suis trompé sur l'un de ces points.

Quelle serait la meilleure approche ici?

Réponse populaire

Le problème que je vois avec les clés de substitution est qu’elles n’ont aucune pertinence pour la logique métier elle-même.

C'est en fait l'avantage, pas le problème. La valeur de la clé est l'identificateur immuable de l'entité, indépendamment de tout autre changement. Je doute vraiment qu'il existe un ORM largement utilisé qui ne puisse pas facilement l'utiliser, car l'alternative (les modifications en cascade d'une valeur clé pour chaque enregistrement enfant) est tellement plus difficile à mettre en œuvre.

Je suggère également que vous ajoutiez une valeur à vos niveaux de difficulté qui permet à la hiérarchie de difficulté croissante d'être représentée dans le modèle de données, sinon "plus difficile que" ou "plus facile que" ne peut pas être représenté de manière robuste.




Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Est-ce KB légal? Oui, apprenez pourquoi