Discussion :

[Li0303]

Bonjour à tous,

Je travaille sur une DB contenant actuellement une 50aine de tables et qui risque encore d'évoluer au fil du temps. (Il s'agit d'une base SQL Server Express (pour le développement mais qui sera migrée en "pro" en production; et j'utilise EF 6)

Il s'agit d'un logiciel ERP gérant, entre autres, les flux commerciaux d'une entreprise ainsi que la gestion du stock.

Je vais décrire un exemple pour illustrer ma question :

Une table "Entête de commande" (CMD) avec une clé primaire composée d'un préfixe et un numéro de commande.
Une table "Détails de commande" (CMDA) avec une clé primaire composée d'un préfixe, d'un numéro de commande, et d'un numéro de ligne. (il y a donc un lien "one to many" entre l'entête et le détails; avec possibilité de ne pas avoir de détail)
Une table "sous détail de commande" (CMDAB) avec une clé primaire composée d'un préfixe, d'un numéro de commande, d'un numéro de ligne, et d'un "item" de sous-détail. (avec un lien "one to many" entre le détail et le sous-détail et la possibilité de ne pas avoir de sous détail)
Une table "Customer" avec une clé primaire composée d'un champ "ID_CUSTOMER" (liée à la table entête de commande par 3 champs : (CMD.CLIENT_ID, CMD.CLIENT_FAC_ID, CMD.CLIENT_EXP_ID car la commande peut être lié à un client mais avoir des informations de livraisons liées à un autre client, idem pour la facturation).

Sur le même schéma, j'ai 3 tables pour lier les expéditions avec un lien entre les lignes de détails de mes expéditions et des lignes de détails de commande. (1 ligne de commande pouvant être liée à plusieurs lignes d'expédition)

Chaque ligne de détail ou de sous détails comportent un champ "PRODUCT_ID" qui les lie à une table "PRODUCT" reprenant les produits vendus ou achetés.

...

(Il existe encore plusieurs autres types de lien)

Les indexes et clés primaires sont configurés pour chaque table mais je n'ai créé aucun diagramme relationnel dans SQL Server Management Studio; donc actuellement les seuls liens existants se trouvent dans ma petite tête.

J'aurais aimé savoir s'il était intéressant de créer ce diagramme et de définir toutes les relations entre les différentes tables avant de générer mon modèle EF dans Visual Studio ? J'ai beau chercher je n'ai pas trouvé l'information et je souhaite structurer un maximum mon travail. (Je m'occupe seul de la DB mais d'autres développeurs me rejoignent pour le reste du travail)

La finalité est de travailler avec un MVVM (.NET, C#)

Merci d'avance pour vos retours

[soazig]

bonjour,
Il y a deux avantages à créer tes foreign key dans la base de données
a/Si quelqu'un pour des raisons de maintenance fait un update direct de la base de données, il ne pourra pas rompre ton modèle.
b/Selon comment tu crées ton modèles entity framework, tu peux le récupérer depuis la base de données. En database first il est beaucoup plus pratique que le modèle soit juste avant de le genérer dans entity framework, sinon c'est la galère. En code first, il existe des outils pour générer le modèle entity à partir de la base.

PS: Tu peux créer tes foreign key sans créer de schema visuel dans SQL server.

Cordialement
Soazig

[StringBuilder]

Bonjour Li0303,

En effet, créer les clé étrangères est un réel plus, car cela permet d'éviter de se retrouer avec des lignes orphelines.

Cela permet aussi de grandement améliorer les performances lors des requêtages suivant ces jointures.

Autre point, qui n'a pas grand chose à avoir, mais un peu quand même : actuellement, tu utilises des clés primaires composées.
Je te conseille grandement de respecter la règle de Codd qui consiste à ce qu'une clé soit technique et dénuée de sens... et unitaire.

Ainsi, que ce soit les clients, commandes, lignes de commande, détails de commandes, factures et livraisons, je te conseille :
- De leur mettre une clé primaire en int ou bigint, autoincrémentée : les index seront bien plus petits, et donc plus performants
- De se service de cette clé pour créer tes relations entre tables : les jointures seront plus aisées à écrires, avec la garantie de bien suivre les relations sans sauter par dessus (par exemple jointure entre CMD et CMDAB sur uniquement le numéro de commande, qui serait contre-performant)
- De mettre tes clés actuelles sous forme de clés alternatives (contraintes uniques) afin que pouvoir travailler exclusivement sur les index lors du filtrage par ces numéros
- De ne pas répéter les éléments de clés dans les sous-table : une ligne de détail de commande ne doit pas contenir ni l'ID interne de la commande, ni son numéro, uniquement l'ID interne de la ligne de commande à laquelle il se rapport ainsi que le numéro d'item, avec une clé unique sur (CMDAB.CMDA_ID, CMDAB.ITEM_ID)

En effet, même si lors des SELECT ça va obliger à consulter les tables CMD et CMDA pour retrouver le numéro de commande lorsque tu travailles sur CMDAB afin d'afficher ton identifiant actuel (l'identifiant applicatif), cela sera plus performant. SQL Server ne travaillera de toute façon que sur les index, pas sur les tables elles-mêmes, qui seront plus petite car moins redondantes.

Un autre avantage, c'est que si le préfixe d'une commande change (erreur de saisie + correction) tu n'as besoin de modifier que l'entête, pas les lignes et le détail... et qui sait quoi d'autre à l'avenir.

Il en résultera une application bien plus facile à maintenir et faire évoluer.

[star]

Un peu de théorie sur les Formes normales : https://fr.wikipedia.org/wiki/Forme_normale_(bases_de_données_relationnelles)

Un peu d'histoire sur le modèle de données relationnel qui a été défini en 1970 par l'informaticien britannique d'IBM Edgar F. Codd : https://fr.wikipedia.org/wiki/Base_d..._relationnelle
.

[DotNetMatt]

Depuis 2017, j'espere que l'OP a quand meme reussi a se documenter

[soazig]

Désolée pour le déterrage de topic, je n'avais pas fait attention à la date.
Oups.

[StringBuilder]

Rho ben c'est malin, et moi qui raconte un roman en plus

[soazig]

A ma décharge, on était quand même sur la première page, je ne suis pas aller chercher le 50 eme post.
Mais c'est un forum très peu actif.
Encore désolée.
Soazig