Discussion :

[Li0303]

Bonjour à tous,

Notre DB contient 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 - Nous travaillons en N.ET, WPF (C#) et nous baserons sur un MVVM)

L'a solution est 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)

Merci d'avance pour vos retours

[Pol63]

côté base de données ca permet d'assurer l'intégrité des données même s'il y a des bugs dans ton code
genre si tu veux insérer un product_id qui vaut 8 alors que dans la table product il n'existe pas ca plantera (ce qui vaut mieux que d'insérer des fausses données)

côté EF ca permet d'avoir des propriétés typées, et que les classes soient reliées entre elles selon le schéma déduit des clés étrangères
en l'occurrence sur la classe générée pour les lignes de commandes tu auras une propriété de type collection de product plutôt qu'un int32, ce qui est assez pratique

[Li0303]

Merci pour la réponse!

Et sachant que ma table PRODUCTS sera liée indépendamment avec tout un ensemble de tables (2 par modules en moyenne donc sans doute une 20 aine au minimum); est-ce que cela pose problème ?

Dois-je générer des diagrammes SQL par flux voire par module pour plus de clarté ou un diagramme global reprenant la totalité des tables?
(exemple : je crée un diagramme "Achats" qui reprend les 3 tables par module (Entête, Détails, Sous-détails) + PRODUCTS (chaque fois lié aux détails et sous-détails) + la table "fournisseurs" + les lien entre chaque module (exemple lien entre une ligne de commande et sa ligne d'expédition + lien entre cette même ligne d'expédition et la ligne de facture, et ainsi de suite)

[Pol63]

un schéma est une aide visuelle
sql server permet de faire des schémas, où l'on fait figurer les tables qu'on choisit, les liens entre les tables présentes y sont représentés
donc tu fais autant de schémas que tu veux par type de flux ou autre, et seules les relations affichables seront affichées

mais les relations sont à faire sur les tables directement pas sur les schémas (enfin ca doit être possible ...)

[Li0303]

Effectivement, je me suis un peu emmêlé les pinceaux dans ma réflexion. (les clés étrangères peuvent être générées également à la création d'un schéma mais elles sont effectivement liées aux tables et non aux schémas à proprement parlé )

[Li0303]

Est-ce que quelqu'un sait s'il existe des extensions ou frameworks permettant d'effectuer un scaffolding MVVM-EF ? J'ai pu tester cela sur le trial de la suite DevExpress et, avec un bon modèle de données (généré par EF après avoir défini toutes mes clés étrangères en SQL), leur "Wizard" génère automatiquement les ViewModels permettant d'effectuer des opérations CRUD sur chaque tables, avec également une gestion des liens master-détails (basé sur les clés primaires), c'est assez incroyable.

Par contre la suite coutant plusieurs milliers de dollars et n'étant intéressé que par cette fonctionnalité particulière, je vous avoue être un peu refroidi...