Discussion :

[Invité]

Bonjour,

J'ai développé un outil en php/mysql. Et je compte faire une 2ème version mieux développé.
Du coup, je me dis que ce serait quand même dommage de repartir sans faire un point sur la BDD.

Elle est assez simple, par contre, j'avais posté un bout sur un forum et une personne avait relevé un souci.
Le reste étant vraiment très simple, je vous donne seulement le bout qui semblerait poser problème.

Dans mon projet, une facture possède plusieurs projets mais un projet n'a qu'une seule facture. Cela donne :

FACTURES (id_facture, date_facture, total_net, langue, délai, type_paiement)
PROJETS (id_projet, date_debut, date_fin, nb_mots, prix_mot, id_facture, id_client)

Dans Projets, on remarque que j'ai aussi un lien vers la table CLIENTS.

J'avais eu un problème pour faire un calcul et "on" avait relevé un problème de conception. Normalement, il faudrait une table intermédiaire entre Factures et Projets genre LIGNES_FACT (id_ligne, id_facture, id_projet)

Je voulais donc avoir votre avis.

En vous remerciant,
Orygynz

[punkoff]

bonjour,


vous parlez de projet, de facture mais jamais des clients ni des lignes.

Commencez par exposer clairement vos besoin fonctionnel et on pourra, alors, comprendre ce que vous voulez modéliser.

[Invité]

Alors c'est un outil de gestion projets (1 projet = 1 client mais 1 client peut avoir plusieurs projets) qui permet ensuite d'éditer des factures (1 facture = plusieurs projets mais 1 projet n'a qu'une seule facture).

Il y a une table client (id_client, nom, adresse, etc...) qui est lié à la table projets. Il n'y a pour l'instant pas de lignes, je voulais savoir si justement il fallait une table intermédiaire dans la conception.

En fait, j'avais posté un problème de requête pour avoir le total de la facturation par client. J'étais obligé de passer du coup par la table projets, et ça donnait ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SUM(F.total_net) AS sum_facture
FROM
    (
      SELECT DISTINCT P.id_client, F.id_facture
        FROM
            PROJETS P
                INNER JOIN FACTURES F
                    ON F.id_facture = P.id_facture
    INNER JOIN CLIENTS C
            ON P.id_client = C.id_client
            WHERE F.num_facture LIKE ?           
                    AND date_format(F.date_facture, "%m") LIKE ?
                    AND date_format(F.date_facture, "%Y") LIKE ?
                    AND C.nom_client LIKE ?
         
    ) AS FM
        INNER JOIN CLIENTS C
            ON FM.id_client = C.id_client
        INNER JOIN FACTURES F
            ON FM.id_facture = F.id_facture

Du coup, la personne qui m'avait aidé, avait soulevé un problème de conception, il disait qu'il fallait une table intermédiaire (que j'ai appelé lignes sur le 1er post mais qui n'existe pour l'instant pas).

Merci !

[punkoff]

si vous linkiez l'ancien poste ca serai plus claire.

Poser une requete sans rien dire de plus ca va pas aider à faire avancer la tembouille.

C'est pour ça que je vous disais d'exposer clairement votre fonctionnel.

si vous voulez revoir la modélisation il faut re-partir du début.

Il y a un forum modélisation sinon : http://www.developpez.net/forums/f62...sation/schema/

[Invité]

Du coup, il faudrait qu'un modérateur transfère ce sujet en modélisation peut-être ?

En fait, mon outil est fonctionnel depuis 1 an et demi maintenant... Le post n'était pas sur ce forum.

Après, je ne pense pas que la base a un problème de modélisation, je l'ai modélisé comme on m'a appris durant mes études. Mais vu que je refais une version plus fonctionnel en php/mysql et maintenant javascript. Je souhaitais me poser la question sur la modélisation. Je ne prétends pas tout connaître et une personne m'a alerté.

Après j'ai l'impression d'être clair. Mon fonctionnel est très simple, il y a seulement cette partie :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
FACTURES (id_facture, date_facture, total_net, langue, délai, type_paiement)
PROJETS (id_projet, date_debut, date_fin, nb_mots, prix_mot, id_facture, id_client)
CLIENTS (id_client, nom, adresse)

Avec les phrases pour la conception :
1 facture a plusieurs projets mais 1 seul client
1 projet a 1 seul facture et 1 seul client

La question est juste de savoir si le lien entre ces 3 tables devrait être corrigé avec un table intermédiaire. Pour ne pas avoir une requête imbriqué avec un DISTINCT pour obtenir le total par client pour une période donnée. En gros, est-ce que la requête que j'ai posté prouve que j'ai un problème de modélisation.

Merci.

[punkoff]

Votre modélisation n'est pas en accord avec les regles que vous cité.


Concernant les tables d'associations ce lien vous aidera à comprendre le passage MCD => MPD : http://blog.developpez.com/cinephil/...le_associative



Pour reprendre votre problème :

1 facture a plusieurs projets mais 1 seul client
Client-0,n-------Paie------1,1-Facture-0,n--------Concerne-------1,1-Projet


1 projet a 1 seul facture et 1 seul client
Client-0,n----------Associé------1,1-Projet--------Concerne------0,n-Facture

Lors du passage au MPD la table facture aura une clef étrangère qui pointera sur la table client (non mentionnée dans votre poste).
Sauf si vous décidez, en toute connaissance, d'omettre la relation "Payer".


On peut voir ici qu'il y a un cycle entre vos 3 entités. Et du coup sans CIF on peut avoir une disconcordance entre les facture et le couple projet/client.
=> un client peut être associé à une facture qui concerne un projet qu'il n'a pas developpé


A partir du moment où vous faites une facture globale, qui regroupe n projet, sans donner la possibilité au client de payer par projet ou en plusieurs fois, une notion de ligne de facture ne me semble pas nécessaire.

Vous perdez en détail par contre vu qu'une facture peut concerner un projet qui a été effectué il y a 10ans comme il y a 2 semaines.

edit: ah, vu que le poste a été déplacé dans le bon forum, d'autre personne auront surement un avis sur la question

[Invité]

Quand vous dites

Votre modélisation n'est pas en accord avec les regles que vous cité.

vous voulez dire pour avoir une bonne cohésion au niveau conceptuel ? Car sinon, les règles fonctionnent de cette façon dans la BDD.

Du coup, en attendant d'autres avis, vous vous pensez qu'il faut laisser comme ça en perdant en détail ? Ou bien modifier la BDD pour la rendre meilleure ?

[punkoff]

Du coup, en attendant d'autres avis, vous vous pensez qu'il faut laisser comme ça en perdant en détail ? Ou bien modifier la BDD pour la rendre meilleure ?

A partir du moment où, d'un point de vue fonctionnel, vous n'avez pas besoin d'introduire la possibilité à un client de pouvoir payer en plusieurs fois ou de ventiler une facture totale par projet je penses que votre modélisation est ok.




Mon précedent commentaire :

Votre modélisation n'est pas en accord avec les regles que vous cité.

peut être ignoré car l'association "Payer" que j'ai rajouté peut être facilement supprimer sans perte d'information.

[Invité]

Ok merci, effectivement, je n'ai pas ce besoin, le client a 3, 5, 12 projets dans un mois donné et on lui fait une facture mensuel en reprenant chaque projets.

La requête permet juste d'afficher le total de facturation d'un client, par exemple, entre Mars et Juin.

[Invité]

Je relance une fois le post avant de le clôturer, histoire d'avoir d'autres avis.

En fait, quand j'y repense, la chose qui peut choquer dans la conception de cette BDD. C'est qu'une facture n'est pas directement lié à un client. Facture -> Projets -> Clients.
Du coup, est-ce que cette situation peut amener des problèmes dans le futur ?
Étant donné que je vais revoir le site et repasser toutes mes requêtes avec la norme JOIN plutôt que WHERE, ça m'éviterait de tout revoir une 3ème fois

Merci à vous

[Richard_35]

Bonjour Orygynz et Punkoff,

Punkoff, je me permets de m'immiscer...

Suggestion :




donnant:

Client(IdClient, ...) ;
Projet(IdProjet, #IdFacture, #IdFacture_Detail, #IdClient, ...) ;
Facture_Entete(IdFacture, #IdClient, ...) ==> #IdClient : c'est l'usage, par facilité ;
Facture_Detail(#IdFacture, IdFacture_Detail, ... ) ==> IdFacture_Detail : numérotation des lignes.

[Invité]

Merci pour le schéma !

Par contre, je pose une question peut-être stupide mais pourquoi ne pas directement mettre un id_client dans la table facture ?

[Richard_35]

pourquoi ne pas directement mettre un id_client dans la table facture ?

==> il y est !...

Client(IdClient, ...) ;
Projet(IdProjet, #IdFacture, #IdFacture_Detail, #IdClient, ...) ;
Facture_Entete(IdFacture, #IdClient, ...) ==> #IdClient : c'est l'usage, par facilité ;
Facture_Detail(#IdFacture, IdFacture_Detail, ... ) ==> IdFacture_Detail : numérotation des lignes.

[Invité]

Oui effectivement, je me suis mal exprimé. En fait, l'ID client mais en laissant une seule table Facture.

Car dans le schéma, je vois pas l'intérêt d'avoir 2 tables FACTURES.

[Richard_35]

je vois pas l'intérêt d'avoir 2 tables FACTURES

==> eh bien, dans ton premier post, tu indiquais :

une facture possède plusieurs projets

==> ce qui veut dire, par exemple, que la facture n° 152 concerne les projets 542,1562 et 3520. Le n° 152 est une information d'entête (Facture_Entete) qui se propage sur les lignes (Facture_Detail). Il faut donc incrémenter un compteur de facture qui sera le même pour toutes les lignes.

Il est d'usage d'utiliser une structure entête/détail, pour les factures, l'entête comportant les attributs communs à tous les projets facturés (N° de facture, client, etc...), le détails comportant les attributs propres à un projet facturé (n° de projet, ...).

Maintenant, tu peux décider, effectivement, ne te servir que d'une seule table, mais tu devras écrire plusieurs fois les mêmes informations car elles seront communes à toutes les lignes. Tu devras, par code, "simuler" cette notion d'entête/détail. Ensuite, tu devras procéder par regroupement (GROUP BY) pour exploiter cette unique table.

Par expérience, je peux te dire que la solution entête/détail est la meilleure et la plus évolutive.

[Invité]

J'avoue être un peu perdu par la solution proposée, je vais copier les tables dont on parle pour être plus concret.

CLIENTS:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE IF NOT EXISTS `clients` (
  `id_client` int(5) NOT NULL AUTO_INCREMENT,
  `nom_client` varchar(50) NOT NULL,
  `adresse` varchar(50) NOT NULL,
  `cp` varchar(10) NOT NULL,
  `ville` varchar(50) NOT NULL,
  `pays` varchar(50) NOT NULL,
  PRIMARY KEY (`id_client`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=8 ;

FACTURES:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
CREATE TABLE IF NOT EXISTS `factures` (
  `id_facture` int(5) NOT NULL AUTO_INCREMENT,
  `num_facture` varchar(15) NOT NULL,
  `date_facture` date NOT NULL,
  `langue` varchar(20) NOT NULL,
  `total_net` decimal(10,2) NOT NULL,
  `type_paiement` varchar(20) NOT NULL,
  PRIMARY KEY (`id_facture`),
  UNIQUE KEY `num_facture` (`num_facture`),
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=66 ;

PROJETS:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE TABLE IF NOT EXISTS `projets` (
  `id_projet` int(5) NOT NULL AUTO_INCREMENT,
  `reference` varchar(150) NOT NULL,
  `description` varchar(255) NOT NULL,
  `lang_source` varchar(30) NOT NULL,
  `date_d` date NOT NULL,
  `date_f` date NOT NULL,
  `nbjours` int(5) NOT NULL,
  `prix_mot_m1` decimal(10,4) NOT NULL,
  `prix_mot_m2` decimal(10,4) DEFAULT NULL,
  `nbmj` int(15) NOT NULL,
  `total_mots` int(10) NOT NULL,
  `mots_m1` int(10) NOT NULL,
  `mots_m2` int(10) DEFAULT NULL,
  `total_prix_proj` decimal(10,2) NOT NULL,
  `match_m1` varchar(20) NOT NULL,
  `match_m2` varchar(20) DEFAULT NULL,
  `id_client` int(5) NOT NULL,
  `id_facture` int(5) DEFAULT NULL,
  PRIMARY KEY (`id_projet`),
  KEY `projets_ibfk_1` (`id_client`),
  KEY `fk_idfact` (`id_facture`),
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=574 ;

Du coup, dans ta technique, je confonds les détails car j'ai l'impression de ne pas en avoir bcq pour factures, au contraire de projets...
Et c'est PROJETS qui fait office de lien...

[Richard_35]

Bonjour Orygynz,

J'avoue que ta solution est simple et elle fonctionne. Le MCD correspondant :



donnant :

Client(IdClient, ...)
Facture(IdFacture, num_facture, ...)
Projet(IdProjet, #IdClient, #IdFacture)

ce qui respecte la règle de gestion que tu as fixée :

une facture possède plusieurs projets mais un projet n'a qu'une seule facture

mais, qui n'est pas très évolutif.

Trois remarques :

• la clé étrangère #IdFacture de la table Projet va rester NULL tant que le projet n'est pas facturé, ce qui est fortement déconseillé ;
• le jour où un projet devra être facturé en deux fois, la conception même de la base de donnée devra être retouchée, ce qui est, également, fortement déconseillé en cours de production ;
• plusieurs champs de ces trois tables devraient être externalisés sous peine de contenus différents pour une même cible (ville Paris différent de Parsi, en cas d'erreur de saisie, ce qui faussera les analyses futures).

Enfin, il serait intéressant que tu en dises davantage sur :

j'avais posté un bout sur un forum et une personne avait relevé un souci.
Le reste étant vraiment très simple, je vous donne seulement le bout qui semblerait poser problème.

et

J'avais eu un problème pour faire un calcul et "on" avait relevé un problème de conception.

En résumé, pas la peine de donner un lien vers toute la discussion...

En annexe, il est d'usage de laisser au singulier le nom des entités (on se doute qu'il y aura, à terme, plusieurs enregistrements dans les tables finales, du moins je l'espère...).

[Invité]

Ok merci pour toutes ces explications.

Pour le problème de conception, c'est relevé par une personne. Voilà pourquoi j'avais ouvert ce sujet. Après, j'étais plus ou moins d'accord vu la complexité pour retourner le montant total facturé d'un client pour un temps donné. Cette requête n'a qu'une seule utilité vu que je peux très bien faire un SUM sur le total des projets du client. C'est pour contrôler ma facturation...
En effet, j'ai eu un souci vu qu'un projet a eu son montant total modifié après facturation... Mais là, clairement, c'est une erreur développement, l'utilisateur n'aurait pas dû avoir le droit de modifier un prix déjà facturé. C'est ce genre de problème que je vais corriger dans la V2.

Pour les remarques :

- Effectivement, l'id_facture reste NULL à la création du projet. Pourquoi est-ce déconseillé ?
- Normalement, un projet ne sera jamais facturé en 2 fois. A la limite, un étalement des paiements mais c'est côté facture.
- Pour la 3ème remarque, je comprends bien l'erreur de saisie, mais tu entends quoi par externalisé pour éviter les erreurs de saisie ? Créer une table VILLE qui reprend toutes le villes de France et choix par liste déroulante ? (le problème, les clients sont majoritairement étrangers)

Pour l'annexe, j'en prends note, elle est pleine de bon sens, je vais sûrement modifier tout ça. Ce sera toujours un caractère en moins sur les lignes de codes ! :-D

[Richard_35]

Pour le problème de conception, c'est relevé par une personne.

==> quel est ce problème de conception ?

En effet, j'ai eu un souci vu qu'un projet a eu son montant total modifié après facturation...

==> si la facture initiale en question a été envoyée au client, comptablement, il faut générer un avoir et créer une autre facture... et là, pour le coup, tu auras besoin de plusieurs factures pour le même projet.

Effectivement, l'id_facture reste NULL à la création du projet. Pourquoi est-ce déconseillé ?

==> c'est un sujet qui fait couler beaucoup d'encre, sur le forum !... voir les sujets de fsmrel. Pour des problèmes de performances et d'évolutivité.

Normalement, un projet ne sera jamais facturé en 2 fois.

==> le "normalement" édulcore le "jamais", non ?...

Pour la 3ème remarque, je comprends bien l'erreur de saisie, mais tu entends quoi par externalisé pour éviter les erreurs de saisie ? Créer une table VILLE qui reprend toutes le villes de France et choix par liste déroulante ?

==> tu pourrais prévoir une table de référence à remplir dans l'application, ça limite les dégâts. L'idéal est de limiter la mise à jour de ce genre de table à un nombre limité d'utilisateurs.

(le problème, les clients sont majoritairement étrangers)

==> a fortiori : les erreurs de saisie seront d'autant plus fréquentes !... Munich, München, Munchön...

[Invité]

Le problème de conception, c'était de devoir faire une requête aussi complexe (celle avec le DISTINCT) pour juste obtenir le montant total des factures d'un client pour un temps donné. Tout simplement.

La facture était bonne, c'est la modification du projet qui était mauvaise... Enfin c'est assez compliqué, c'est à cause de montant à 3 / 4 chiffres après la virgule, l'utilisateur peut modifier le total après calcul ! (ça aussi, je souhaite le modifier dans la V2).

Le "normalement", j'étais sûr que tu allais répondre ça !

Pour la ville, il s'agit de fiche client qui sont facilement modifiable en cas d'erreur de saisie... Bon après, c'est sûr, la personne doit se relire à un moment ou un autre... (facturation)

Pour l'instant, cet outil ne sert qu'à une seule personne... Je vais faire une V2 pour permettre l'utilisation de cet outil sur plusieurs années sans revenir dans le code. Pour l'instant, j'ai trop de petits détails qui gâche l'outil et qui peuvent le rendre dangereux... (cf les exemples donnés) Et après, mais vraiment dans un second temps, pourquoi ne pas le mettre à disposition sur le net... Je pense qu'il pourra être utile...