Discussion :

[jacquesprogram]

Bonjour,
je me pose plusieurs questions au sujet d'EF.
J'ai une base de données SQLite (créée par un logiciel tiers). J'ai créé un modèle d'Entités basé dessus via l'assistant. Je n'ai besoin d’accéder à cette base qu'en lecture.
Cependant, j'ai besoin de modifier le modèle créé, pour me simplifier la tâche au niveau de l'affichage des données. En particulier, j'ai besoin de créé toutes les relations entre les tables (qui n'existent pas dans le fichier bd original). J'ai commencé à le faire à partir du diagramme de mon modèle et là, plusieurs questions:
soient les tables A et B.
A

• ID (clé primaire, Int64)
• Description (String)
• Type (String)

Et la table Types

• ID (clé primaire, Int64)
• Description (String)

Dans le fichier SQLite original, la colonne Type de la Table A contient la donnée figurant dans la colonne Description de la table Types (et non pas la clé primaire ID). J'aimerais la même chose dans mon modèle:
lors de la création de la relation (je rappelle qu'aucune relation n'existe dans mon modèle vu qu'elles n'existent pas dans la bd originale), j'aimerais que celle-ci utilise la colonne Description et non pas ID de la table Types. Dois-je changer la clé primaire de la table Types (pour la passer sur la colonne Description) ?
Sinon, j'ai pensé laisser l'assistant de création de relation créer une nouvelle propriété dans la table A contenant la clé étrangère et utiliser ensuite celle-ci lors de l'affichage des données.
Quelle est la bonne solution ?

[Alexandre le Grand]

Bonjour,

Dans le fichier SQLite original, la colonne Type de la Table A contient la donnée figurant dans la colonne Description de la table Types (et non pas la clé primaire ID).
Sinon, j'ai pensé laisser l'assistant de

Votre modèle a l'air de ne pas être bien fait. Normalement, votre colonne Type de la Table A devrait contenir la clé de la Table Type. C'est ce que je vous conseille comme modèle.
A défaut, si vous voulez suivre le modèle préétabli, il vous faudra vous assurer que toutes les données de la colonne Description de la Table Type, sont uniques, sinon vous aurez des erreurs (bugs).

[jacquesprogram]

Le modèle créé par le logiciel tiers est parfaitement valide. Dû à des contraintes techniques, la validité de la base et les relations sont réalisées par code.
En ce qui me concerne, je dois suivre ce modèle. Mais je me demande si modifier le modèle d'Entités est la bonne solution...

[DotNetMatt]

Le modèle créé par le logiciel tiers est parfaitement valide. Dû à des contraintes techniques, la validité de la base et les relations sont réalisées par code.

Le modèle n'est pas valide car il n'y a pas de relations entre les tables (pas de clés étrangères), et pas de contraintes d'intégrité référentielle (puisque pas de clés étrangères). Et pour couronner le tout, la relation entre les tables "A" et "Types" se fait sur le champ "Description"... Cela va à l'encontre des règles fondamentales de modélisation : les clés ne doivent jamais être de type texte pour la simple et bonne raison que c'est anti-performant, contrairement aux entiers, qui sont très légers à manipuler et permettent d'obtenir de bonnes performances sur les jointures.

De plus le contrôle de l'intégrité référentielle doit être délégué au SGBDR car il est le seul à pouvoir gérer ça convenablement, et en plus ça épargne des tartines de code inutile pour faire quelques vérifications avant insertion/modification/suppression...

[Alexandre le Grand]

Le modèle n'est pas valide car il n'y a pas de relations entre les tables (pas de clés étrangères), et pas de contraintes d'intégrité référentielle (puisque pas de clés étrangères). Et pour couronner le tout, la relation entre les tables "A" et "Types" se fait sur le champ "Description"... Cela va à l'encontre des règles fondamentales de modélisation : les clés ne doivent jamais être de type texte pour la simple et bonne raison que c'est anti-performant.

@jacquesprogram, Je te conseillerai de suivre les recommandations de DotNetMatt, pour la simple et bonne et raison référencée ci dessous. A la rigueur tu pourras indexer le champ Description.

Merci.

[jacquesprogram]

Merci pour vos réponses.
La base est telle qu'elle est, je ne peux pas la changer. Elle est créée par un jeu vidéo et si elle a été créée ainsi par les programmeurs, c'est pour des raisons techniques essentielles qu'il serait inutile et trop long d'exposer ici.
Mon questionnement est: la base étant ainsi, comment moi, puis-je faire pour me faciliter la vie au niveau affichage (je rappelle que je n'ai pas besoin d'y écrire): passer par EF, est-ce la bonne solution ? A ce moment-là, dois-je créer moi-même le modèle avec les relations et clés étrangères qui vont bien et "importer" à la main, par code, le contenu de la base originale en faisant au passage les ajustements nécessaires, ou créer un Dataset, ou encore autre solution ?

[DotNetMatt]

Dans ton cas, et vu qu'il n'est pas possible de toucher à la base de données, je ne pense pas qu'il y ait de solution plus judicieuse qu'une autre.

On peut toutefois écarter tout ce qui est lié aux DataSets, car ils génèrent un overhead important (ils embarquent plein de fonctionnalités inutiles...) et c'est plus une boîte noire qu'autre chose. Il est difficile de contrôler précisément ce qu'il s'y passe. De plus les DataSets ont été créés au tout début de l'existence du .NET Framework car il n'existait pas à l'époque toutes les mécaniques d'aujourd'hui (ORMs, ADO.NET...), donc pour moi ça relève plutôt de la préhistoire ou alors ça peut aider pour monter une démo très rapidement, en utilisant les assistants de Visual Studio...

Personnellement, j'opterai :

- Soit pour la mise en place d'un modèle EF. Même si au niveau du modèle, tu n'auras pas de relations entre les entités puisqu'elles n'existent pas dans la base de données. Avantage : tu auras rapidement une mécanique fiable et évolutive pour pouvoir gérer tes entités (CRUD).

- Soit pour une DAL (Data Access Layer) développée à la main, ce qui aura l'avantage de te donner beaucoup plus de contrôle sur ce qui se passe, donc plus de souplesse... Pour t'inspirer, quelques liens :

• Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 1
• Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 2
• Architecture de couche d'accès aux données (DAL) de hautes performances — Partie 3

[jacquesprogram]

Merci pour ces précisions utiles.
J'abandonne donc l'idée du Dataset.
Concernant, le modèle EF: si je le créé à partir de la bd, il n'y aura effectivement aucune realtion. Mais serait-il envisageable d'en créer un à partir d'un modèle vide, en créant à la main toutes les entités ainsi que les relations et "remplir" les entités par code depuis le fichier bd original ? Bon, ça serait galère pour moi, vu que la bd contient quand-même plus de 200 tables...
En attendant, je vais me plonger dans la doc sur le DAL.
Merci.

[DotNetMatt]

Concernant, le modèle EF: si je le créé à partir de la bd, il n'y aura effectivement aucune realtion. Mais serait-il envisageable d'en créer un à partir d'un modèle vide, en créant à la main toutes les entités ainsi que les relations et "remplir" les entités par code depuis le fichier bd original ? Bon, ça serait galère pour moi, vu que la bd contient quand-même plus de 200 tables...

Oui c'est tout à fait possible, à voir :

• Relationships/Associations with the EF Designer
• Foreign Keys in the Entity Framework

Mais attention cela ne résoudra pas le problème sous-jacent (l'inexistence des clés étrangères), ça te permettra juste de pouvoir bénéficier des jointures en utilisant Entity Framework, même si elles ne sont pas réellement présentes dans la base de données.

Après à toi de voir en fonction du projet, si ça vaut le coup d'avoir une DAL pour pouvoir garder le contrôle total sur ce qu'il se passe, ou bien si EF t'offre un bon compromis, au prix d'une opacité un peu plus grande, mais d'un temps de développement raccourci.

[jacquesprogram]

OK. Merci.
Je vais voir tout ça.