Discussion :

[Wisevolk]

Bonjour,

J'aimerai modéliser une base de données de facturation/bon de commandes clients Pro et Particuliers sur une base PostgreSQL (la souplesse du NoSQL aurait été une bonne solution, sans doute sur une prochaine release avec totale refonte....)

J'étais parti sur une structure à 4 tables (hormis les sous tables que je ne n'expose pas pour la simplicité du post), même si j'aurai pu exploiter la table Factures pour les bdc je prefère les séparer principalement pour des raisons de droits mais également de gestion.

* Factures (id, personne_id, societe_id.....) avec soit personne_id doit societe_id pouvant être null selon à qui est destiné la facture.
* Bdc (id, personne_id, societe_id.....) doit avec personne_id doit societe_id pouvant être null selon à qui est destiné le bon de commande.
* Societes (id....)
* Personnes (id, societe_id ...) societe_id etant null si il s'agit d'un particulier.

Une autre solution aurait été de créer une structure comportant une 6 bases principales mais du coup le nombre de sous tables augmentent tout autant et on se retrouve avec beaucoup de redondance :
* Societe
* Facture_Societe
* Bdc_Societe
* Particulier
* Facture_Particulier
* Bdc_particlier

Quel serait le choix le plus propres et auriez-vous d'autre solution à proposer toujours dans un cadre SQL.

Merci

[Mat.M]

J'aimerai modéliser une base de données de facturation/bon de commandes clients Pro et Particuliers

ça c'est un problème archi-classique des bases de données
en général on a une table facture avec un numéro/référence, date d'émission et montant total ( en anglais Invoice Order j'écris ça pour les gens qui utilisent des ERP )
Ensuite on crée une table avec les lignes de facturations , montant unitaire hors-taxe et le numéro de facture à laquelle la ligne de facture est rattachée ( Invoice Detail)

Une autre solution aurait été de créer une structure comportant une 6 bases principales mais du coup le nombre de sous tables augmentent tout autant et on se retrouve avec beaucoup de redondance :
Quel serait le choix le plus propres et auriez-vous d'autre solution à proposer toujours dans un cadre SQL.

avant de faire le schéma d'une BDD relationnelle il faudrait effectuer la normalisation de la base de données en elle-même ( 1ière,2ième,3ième forme normale...)
ça permet d'éviter les redondances
*tuto de DVP
*explications Microsoft
Wikipedia mais un peu compliqué

[Wisevolk]

Merci pour votre réponse,

j'ai sans doute mal exprimé mon interrogation, je n'ai pas de problème pour schématiser la facturation.

Mon problème provient de la schématisation des entités facturées à savoir des Personnes (Particuliers) ou des Sociétés, sachant qu'une société inclue une liste de contacts (table Personnes).

Pour le moment je pars sur ma première structure (4 tables plus les sous-tables) mais je cherchais à savoir s'il n'existait pas une solution(un pattern) plus propre que celle qui consiste à avoir des colonnes comportant des valeurs nulles sans pour autant devoir multiplier le nombre tables.

[SQLpro]

Merci pour votre réponse,

j'ai sans doute mal exprimé mon interrogation, je n'ai pas de problème pour schématiser la facturation.

Mon problème provient de la schématisation des entités facturées à savoir des Personnes (Particuliers) ou des Sociétés, sachant qu'une société inclue une liste de contacts (table Personnes).

Pour le moment je pars sur ma première structure (4 tables plus les sous-tables) mais je cherchais à savoir s'il n'existait pas une solution(un pattern) plus propre que celle qui consiste à avoir des colonnes comportant des valeurs nulles sans pour autant devoir multiplier le nombre tables.

A lire :
https://blog.developpez.com/exercice...n_de_personnes
https://blog.developpez.com/exercice..._d_une_adresse

A +

[aieeeuuuuu]

Bonjour,

je cherchais à savoir s'il n'existait pas une solution(un pattern) plus propre

Si, cela s’appelle l'héritage.
En gros, une table Client, et deux tables (pro et particulier) qui héritent de Client.
Votre table facture peut ensuite référencer directement la table client.

[Wisevolk]

Merci,
entre temps je suis également tombé sur cette solution en parcourant la doc de Postgres
Pour le moment j'ai résolu le problème en modifiant la structure pour une jointure personne/société dans la mesure où une société et "forcément" représenté par un contact.
Je marque le sujet comme résolu, une fois de plus merci pour votre aide.