base de données et python

Version imprimable

14/01/2021, 19h57
Fodchan

base de données et python

Bonjour à tous,

J'ai une base de données avec plusieurs valeurs, je voudrais savoir si il est possible, sur python, de créer une interface (cela peut être un site web) qui permettra à certains utilisateurs qui ne programme pas d'avoir accès aux données de la base de données avec une fonction recherche. Par exemple, imaginons que j'ai cette base de données:

Nom Prénom Nombre d'enfants Famille Caractéristique de la famille

x y z a b

c m l m l

Si l'utilisateur cherche x je dois avoir les informations sur le prénom, le nombre d'enfants, la famille, les caractéristiques. Si il y a plusieurs personnes portant le nom x je dois pouvoir les voir.
Je voudrais savoir si c'est possible, si oui quelles sont les étapes pour y arriver. Je suis débutant en programmation mais si vous me dites les étapes (ou concepts) je pourrais faire mes recherches de mon côté.
Merci d'avance
14/01/2021, 20h37
wiztricks

Salut,

Citation:

Envoyé par Fodchan

Je suis débutant en programmation mais si vous me dites les étapes (ou concepts) je pourrais faire mes recherches de mon côté.

Ouvrez n'importe quel tuto décent sur Python, vous y trouverez des chapitres qui parlent de bases de données et de serveurs Web... Et vous sauriez répondre à ces questions.

- W
14/01/2021, 21h11
fred1599

Bonsoir,

Citation:

je voudrais savoir si il est possible, sur python

Si vous vous posez cette question, c'est que vous avez sans doute beaucoup de chemins à parcourir pour arriver à votre objectif.
Quelque-soit le langage, c'est possible, avec plus ou moins de difficultés certes, mais possible.

Le grand avantage de ce langage, est d'avoir beaucoup d'outils, modules qui permettent de se simplifier la vie...

Donc oui, c'est possible, mais ça sera pas aussi simple, même si on a de l'aide... Apprendre les bases du langage est une nécessité !

Citation:

cela peut etre un site web

Mouais, alors on est encore plus loin, car utiliser un framework Web comme Django ou Flask pour en citer deux connus, nécessite un niveau non pas débutant, mais confirmé.
Il faut comprendre qu'on y ajoute des couches plus complexes encore, comme la POO, le réseau, les bases de données, l'authentification, les WebServices, ...
Et là quelque soit le langage, c'est autres choses à connaître.

Citation:

Je suis débutant en programmation

La vraie question est là, plutôt que poser la question sur les capacités du langage concernant la création d'un serveur HTTP, et où avec un peu de recherches, vous auriez pu trouver la réponse, une chose que Google ou autres moteurs de recherches ne pourront vous donner une réponse, c'est à la question de vos capacités actuelles à pouvoir le faire. Alors actuellement pensez-vous pouvoir faire cela avec vos connaissances actuelles, ne serait-ce hors connaissances du langage Python ?
15/01/2021, 07h16
tyrtamos

Bonjour,

J'adhère aux remarques des collègues: oui, c'est techniquement possible, mais pour y arriver, cela va demander à un programmeur débutant des centaines d'heures de formation et de développement.

Pour la partie confiée à l'utilisateur, il faut faire un programme graphique avec, par exemple, la bibliothèque graphique PyQt5. Celle-ci comporte tout ce qu'il faut pour accéder à une base de données relationnelle, chercher des infos, l'afficher, et la mettre à jour. PyQt5 permet, par exemple, d'afficher une table dans une grille de type tableur avec liaison automatique dans les 2 sens avec la base, grâce à un "modèle".

Il faut, bien sûr, pouvoir construire correctement une base de données relationnelle, qu'elle soit locale ou distante. Si la base de données est distante (=>Internet), il faut avoir résolu les problèmes critiques d'accès (sécurité). Et sa gestion nécessite de connaître le langage SQL qui est très puissant, mais très spécifique.

En résumé, les connaissances qu'il faut acquérir sont en gros:
- Bases de la programmation en général (POO, ...)
- Langage Python
- Bibliothèque graphique PyQt5
- Conception et gestion des Bases de données relationnelles
- Langage SQL
- Administration d'une base de données distante

Et, bien sûr, si la base est distante, il faut disposer d'un hébergement qui la propose (MySQL, Postgre, ...) et permettre un accès sécurisé à distance.

Après tout ça, il faut faire...

A part ça, c'est un beau projet! :D
15/01/2021, 12h12
Fodchan

Bonjour,

Merci pour toutes vos réponses. Je sais que ça va me prendre énormément de temps mais je suis motivé pour apprendre et réaliser ce projet.
Voici mes objectifs:

Citation:

Bases de la programmation en général (POO, ...)
- Langage Python
- Bibliothèque graphique PyQt5
- Conception et gestion des Bases de données relationnelles
- Langage SQL
- Administration d'une base de données distante

C'est exactement ce que je cherchais, maintenant je vais chercher des tutoriels pour voir toutes ces notions. Si jamais vous en avez, n'hésitez pas!
Merci encore
15/01/2021, 22h39
Invité

Pour ma part ça fait plus de 10 ans que je bidouille en Python et je ne me suis intéressé que récemment au base de données avec sqlite3.
Je me suis toujours débrouillé pour stocker mes infos en fichier texte... C'est plus clair dans ma tête ! :oops:
16/01/2021, 13h28
Sve@r

Bonjoir

Citation:

Envoyé par LeNarvalo

Pour ma part ça fait plus de 10 ans que je bidouille en Python et je ne me suis intéressé que récemment au base de données avec sqlite3.

Attention, sqlite3 n'est qu'un ersatz de bdd. Ersatz peut-être très riche, mais si on veut faire de la vraie bdd (accès concurrents, utiliser des clefs agrégées, des contraintes d'intégrité qui cascadent sur les filles, des triggers et fonctions qui permettent d'enchainer automatiquement des actions lors des insert et delete), il faut alors passer à une vraie bdd qui sera alors indépendante de Python. Ca demande évidemment un coût en temps mais selon le besoin ça peut valoir le coup.

Citation:

Envoyé par LeNarvalo

Je me suis toujours débrouillé pour stocker mes infos en fichier texte... C'est plus clair dans ma tête ! :oops:

Tout est possible bien entendu, mais bon quand on arrive à des trucs un tant soit peu complexe (par exemple ne serait-ce qu'une simple gestion de stocks avec nom du produit, nom du fournisseur) le fichier texte montre quand-même vite ses limites.
16/01/2021, 20h11
Invité

Citation:

Tout est possible bien entendu, mais bon quand on arrive à des trucs un tant soit peu complexe (par exemple ne serait-ce qu'une simple gestion de stocks avec nom du produit, nom du fournisseur) le fichier texte montre quand-même vite ses limites.

Je pense que ce qui me limiterait le plus c'est le faite de gérer plusieurs modifications simultanément depuis plusieurs ordis en réseau, vu que je n'y connais rien. :mouarf:
Sinon, des balises dans le fichier texte, 3 semaines à écrire le script avec Tkinter en tant qu'interface graphique et paf j'aurais un logiciel de gestion de stock ! (Tout pourri et peut-être encore plus lent que celui de mon taf, mais bon... SAPANET) :ptdr:
16/01/2021, 20h35
wiztricks

Salut,

Citation:

Envoyé par Sve@r

Attention, sqlite3 n'est qu'un ersatz de bdd. Ersatz peut-être très riche, mais si on veut faire de la vraie bdd .... il faut alors passer à une vraie bdd qui sera alors indépendante de Python.

Si un développeur Python a besoin de plus que sqlite3 alors peut être qu'il devrait se poser la question côté recrutement d'un expert en base de données (un métier à part entière).

- W
17/01/2021, 00h59
fred1599

Qu'est ce qu'un expert ? Faut il être un expert? Pas certains de cette affirmation, à savoir qu'on reste dans le sql... Où j'ai pas compris où tu voulais en venir?
17/01/2021, 09h03
tyrtamos

Bonjour,

Je vois souvent dans les commentaires que sqlite3 serait un produit trop limité pour être utilisé par des gens sérieux: je m'inscris en faux sur ça. La seule vraie limite de sqlite3 est qu'il ne supporte pas les accès concurrents. Mais quand on n'en a pas besoin, il faut vraiment avoir des besoins importants et très complexes pour chercher un autre SGBDR.

J'ai utilisé sqlite3 pendant 10 ans pour traiter les données d'un concours international (5000 articles, 15 tables, encodage unicode, nombreuses contraintes de clés étrangères, triggers, mise à jour par transactions, effacements en cascade, extraction avec sous-requêtes, création de tables temporaires, etc... Et comme le pilote Python permet d'ajouter des fonctions directement utilisables dans les requêtes SQL, il est facile d'ajouter des choses comme: ajout de variables, recherche par expressions régulières ou par mots similaires, tri selon le dictionnaire français, etc... Enfin, si les instructions pour modifier la structure de la base de données (ALTER) sont limitées, il est facile d'y pallier pour faire n'importe quelle modification de structure qu'on veut. J'ai fait en son temps des tutos pour ça.

En plus, la base de données peut être affichée et modifiée en mode graphique avec PyQt5. L'affichage / modification / recherche / filtrage / extraction / transmission à Excel est fait par QTableView et le "model" relationnel. C'était d'ailleurs un de mes critères pour choisir PyQt5 comme bibliothèque graphique. De plus, tout ça supporte très bien le traitement cx_freeze ou pyinstaller, ce qui permet de transporter le programme et sa base de données sur des PC sans Python, même avec une simple clé USB.

A aucun moment je n'ai eu à regretter mon choix, et à aucun moment je me suis retrouvé avec des extractions impossibles ou des problèmes d'intégrité de la base de données.

Il reste que la notion d'expert en base de données est importante et, à part une très bonne connaissance du langage SQL, peut jouer sur d'autres critères, à commencer par la conception d'une base de données relationnelle. Il existe depuis 1970 une logique solide qui permet dès le départ d'avoir une base de données qui sera facile à gérer et à maintenir en bon état. De nombreux sites web en parlent, par exemple:
- https://laurent-audibert.developpez....relationnelles
- https://www.ionos.fr/digitalguide/he...relationnelle/.
- http://cerig.pagora.grenoble-inp.fr/...ees/chap06.htm
Il existe aussi des méthodes puissantes (mais un peu "usine à gaz") comme "Merise" pour construire un bon système d'information dans les grands projets des grandes entreprises.

Sans aller jusqu'aux grosses méthodes, prenons quelques exemples de principes simples qu'on peut utiliser dans un petit projet:
- les tables doivent concerner surtout des entités physiques (clients, fournisseurs, articles, ...), et il faut éviter de créer des tables qui dépendent de l'organisation qui, elle, peut changer à tout moment.
- on ne doit jamais avoir une même information à plusieurs endroits de la base de données, car le risque est qu'on mette à jour cette information à un seul endroit et pas dans tous, ce qui produirait une faute d'intégrité de la base. D'où les contraintes à créer entre les tables.
- quand on a à saisir un nom de pays à plusieurs endroits (adresse d'un client et adresse d'un fournisseur), il ne faut pas qu'on puisse écrire différemment le même pays à chaque fois (Grande-Bretagne, GB, UK, Angleterre, etc...), parce qu'on ne pourrait plus faire d'extraction par pays. Le choix doit donc être limité par une liste des pays reconnus (normes ISO 3166: https://www.iso.org/fr/iso-3166-country-codes.html). Encore une table et une contrainte de clé étrangère à mettre.

Et bien sûr, dans tous ces cas, la mise à jour se fera impérativement sous forme de transactions, de sorte que si, dans une même liste de requêtes de modification, l'une ne passe pas, les requêtes déjà passées doivent être "démontées" pour maintenir l'intégrité de la base.

Etc...

[EDIT] Je m'aperçois que j'ai oublié quelque chose qui peut être important dans certains cas: en plus de ne pas supporter les accès concurrents, sqlite3 ne sait pas gérer les droits d'accès. Comme la base de données sqlite3 est lié à un programme, l'accès à ce programme donne l'accès à la base avec tous les droits. Mais rien n'interdit qu'entre deux cessions du programme cette base de données ne soit conservée cryptée de façon à empêcher les modifications "inappropriées". Si on a besoin de plus de sécurité (droits d'accès lecture/écriture pour chaque utilisateur déclaré), les SGBDR sur serveur (MySQL, Postgre, etc...) deviennent indispensables.
17/01/2021, 11h20
wiztricks

Salut,

Citation:

Envoyé par fred1599

Qu'est ce qu'un expert ? Faut il être un expert? Pas certains de cette affirmation, à savoir qu'on reste dans le sql... Où j'ai pas compris où tu voulais en venir?

Effectivement, nous restons dans le SQL. Mais ce SQL va être exécuté par un moteur de SGDB (qui a des optimisations spécifiques) sur un tas de tables qui auront des relations, des questions d'intégrité et un cycle de vie complètement différent de celui des objets d'une application.

Qu'est ce qu'on fait faire par le SGDB, comment on réalise le schéma suivant le moteur de la base... n'est pas quelque chose qu'on voit au démarrage ou aux tests de l'application mais plus tard lors de montées en charge ou ajouter de nouvelles fonctionnalités.

Il suffit d'aller trainer un peu dans les forums SGDB pour voir que les experts de ce monde là ne pensent pas le problème comme un développeur d'application et posant le problème différemment, ils poussent d'autres solutions souvent intéressantes.

Ce que je dis, c'est qu'il faut connaître ses limites et savoir assez bien ce qu'est un SGDB pour pouvoir, le cas échéant, discuter avec ces expertises là.

Il est clair qu'aujourd'hui on a moins besoin d'expertise: si çà rame, augmenter les capacités sera moins risqué/couteux (à très court terme) que de remettre à plat schéma, tables, application, ....

- W
17/01/2021, 14h18
Sve@r

Citation:

Envoyé par tyrtamos

Je vois souvent dans les commentaires que sqlite3 serait un produit trop limité pour être utilisé par des gens sérieux: je m'inscris en faux sur ça. La seule vraie limite de sqlite3 est qu'il ne supporte pas les accès concurrents. Mais quand on n'en a pas besoin, il faut vraiment avoir des besoins importants et très complexes pour chercher un autre SGBDR.

Sait-il gérer les clefs agrégées (une clef composée de 2 ou plus colonnes) ? J'ai eu ce souci une fois (vers 2005). J'ai alors testé MySQL qui savait à l'époque la gérer en tant que clef primaire mais ne savais pas l'utiliser comme clef étrangère d'une autre table (et donc y appliquer par exemple une cascade quand une partie de la clef primaire change). Et j'ai été content de voir que Postgres, lui, savait le faire. Cela a été la cause de mon basculement définitif vers ce SGBD.

Citation:

Envoyé par tyrtamos

Il reste que la notion d'expert en base de données est importante et, à part une très bonne connaissance du langage SQL, peut jouer sur d'autres critères, à commencer par la conception d'une base de données relationnelle. Il existe depuis 1970 une logique solide qui permet dès le départ d'avoir une base de données qui sera facile à gérer et à maintenir en bon état.

Comme quoi, c'est plus que de simples notions et nécessitent un certain temps d'apprentissage (en référence au post de Fodchan qui veut tout apprendre tout de suite)...
17/01/2021, 14h39
wiztricks

Salut,

Il ne faut pas se braquer sur les SGDB: sqlite3 est très bien tant qu'on l'utilise pour ce qu'il sait bien faire (quitte à s'aider d'un comparatif si on ne sait pas): la "petite" base de donnée portable et libre de droits qu'on peut embarquer dans une application pour avoir des fonctionnalités de persistance intéressantes.

Dès qu'on doit aller au delà, soit on n'a pas le choix parce que le client utilise et à des compétence dans avec le SGDB tartemolle: pas être facile de lui imposer un autre SGDB (pour sqlite, comme c'est "embarqué", le client ne le voit pas).

Et s'il y a un tas de serveurs de bases de données, il va aussi y avoir des administrateurs, des contraintes de performances (on ne va pas nécessairement ajouter des serveurs mais en partager avec d'autres applications), des audits,...

- W
17/01/2021, 18h46
fred1599

Citation:

Envoyé par wiztricks

Salut,

Effectivement, nous restons dans le SQL. Mais ce SQL va être exécuté par un moteur de SGDB (qui a des optimisations spécifiques) sur un tas de tables qui auront des relations, des questions d'intégrité et un cycle de vie complètement différent de celui des objets d'une application.

Qu'est ce qu'on fait faire par le SGDB, comment on réalise le schéma suivant le moteur de la base... n'est pas quelque chose qu'on voit au démarrage ou aux tests de l'application mais plus tard lors de montées en charge ou ajouter de nouvelles fonctionnalités.

Il suffit d'aller trainer un peu dans les forums SGDB pour voir que les experts de ce monde là ne pensent pas le problème comme un développeur d'application et posant le problème différemment, ils poussent d'autres solutions souvent intéressantes.

Ce que je dis, c'est qu'il faut connaître ses limites et savoir assez bien ce qu'est un SGDB pour pouvoir, le cas échéant, discuter avec ces expertises là.

Il est clair qu'aujourd'hui on a moins besoin d'expertise: si çà rame, augmenter les capacités sera moins risqué/couteux (à très court terme) que de remettre à plat schéma, tables, application, ....

- W

Merci pour les précisions, effectivement la conception devrait être faire au démarrage du projet, pas lorsqu'on se rend compte d'éventuels ralentissements ou autres problèmes conceptuels.
Ce qui est dommage, c'est que souvent le développeur fait le travail du DBA, sans aller aussi loin que le ferait l'expert, ce qui a tendance à provoquer des dysfonctionnement par la suite sur le projet.

Bonne soirée ;)
18/01/2021, 15h03
popo

Citation:

Envoyé par tyrtamos

- on ne doit jamais avoir une même information à plusieurs endroits de la base de données, car le risque est qu'on mette à jour cette information à un seul endroit et pas dans tous, ce qui produirait une faute d'intégrité de la base. D'où les contraintes à créer entre les tables.

Attention aux fausses idées reçues ou aux dogmes appliqués sans réfléchir.

Prenons un cas concret d'une entreprise qui gère ses clients et qui les facture pour diverse prestation.
Monsieur Popo est mon client depuis 2015. J'ai donc renseigné son adresse dans mon fichier client pour lui adresser ses factures.
Monsieur Popo est un très bon client et j'ai beaucoup de factures à son nom dans ma base de données.
Il y a une semaine, Monsieur popo a déménagé. Je profite d'une nouvelle commande pour mettre à jour son adresse.
Cette nouvelle adresse figurera sur sa nouvelle facture.
Mais si je dois rééditer une ancienne facture, ce n'est pas sa nouvelle adresse qui doit apparaitre mais son ancienne tel que c'est défini dans la loi française.

La loi française implique donc de dupliquer l'information de l'adresse d'un client à plusieurs endroits.
Le dogme "Pas de redondance de données" est un bon principe mais il faut réfléchir à ce qu'on fait et ne pas l'appliquer à la lettre de manière systématique
18/01/2021, 15h21
wiztricks

Salut,

Citation:

Envoyé par popo

Mais si je dois rééditer une ancienne facture, ce n'est pas sa nouvelle adresse qui doit apparaitre mais son ancienne tel que c'est défini dans la loi française.

Rien n'empêche à un client d'avoir plusieurs adresses de facturations (dont une adresse par défaut) et d'avoir chaque facture associée à une adresse particulière.
Il n'y a pas de redondance de données...

- W
18/01/2021, 15h53
tyrtamos

Bonjour,

Citation:

Envoyé par popo

Le dogme "Pas de redondance de données" est un bon principe mais il faut réfléchir à ce qu'on fait et ne pas l'appliquer à la lettre de manière systématique

Je suis d'accord avec wiztricks: dans l'exemple donné, si c'est prévu comme ça (cahier des charges), ce n'est pas une redondance de données.

Ce principe permet d'éviter certaines bêtises de conception qui rendent la maintenance pénible (voire défaillante).
18/01/2021, 16h45
popo

Citation:

Envoyé par wiztricks

Salut,

Rien n'empêche à un client d'avoir plusieurs adresses de facturations (dont une adresse par défaut) et d'avoir chaque facture associée à une adresse particulière.
Il n'y a pas de redondance de données...

- W

Certes, rien n'empêche à un client d'avoir plusieurs adresses de facturations.
Je conçois que l'adresse ne soit pas le meilleur exemple.
Même si cela reviens à chaque fois que mon client déménage à
- Créer une nouvelle adresse
- Conserver l'ancienne
- Changer l'adresse par défaut.
Donc conserver un historique des adresses (dont la majorité sont obsolètes)

Mais que fais-tu des prix des articles ?
Avec l'inflation, les prix des articles a augmenté.
Si je réédite la facture, je ne dois pas me retrouver avec les nouveaux prix mais bien avec ceux de l'époque.
18/01/2021, 17h45
wiztricks

Salut,

Citation:

Envoyé par popo

Même si cela reviens à chaque fois que mon client déménage à
- Créer une nouvelle adresse
- Conserver l'ancienne
- Changer l'adresse par défaut.
Donc conserver un historique des adresses (dont la majorité sont obsolètes)

Mais que fais-tu des prix des articles ?

On a deux solutions.

Quick & dirty est de conserver le PDF des features pendant la durée légale et avoir un historique de factures par client que l'on peut rechercher manuellement. Elle peut être chargée depuis un robot de sauvegardes et éditée comme duplicata.
Cela garantie la conformité des copies (et met à l'abri des évolutions logicielles qui pourrait les éditer différemment).

Plus cher sera d'avoir un catalogue de produits (avec leurs prix) qui évolue tous les x mois. Une commande est faite avec le catalogue produit valide à la date correspondante (et rendra éventuellement compte des remises consenties suivant le produit, le client).
Une facture est établie suivant la commande à une adresse de facturation donnée.

La différence entre les deux, c'est la possibilité d'avoir un historique sur quelques années qui peuvent aider le marketing à faire des projections...
Mais pour la PME ou l'artisan, çà ne lui servira pas beaucoup.

- W

Nom	Prénom	Nombre d'enfants	Famille	Caractéristique de la famille
x	y	z	a	b
c	m	l	m	l

1 pièce(s) jointe(s)

Bonsoir à tous,

Les problèmes que vous évoquez, et les questions d'historisation en particulier, relèvent tous de la modélisation conceptuelle de votre système d'information.
Si vous arrivez à traduire vos exigences sous forme de modèle conceptuel de données (MCD), le schéma relationnel de la BD se déduira automatiquement.
Par exemple pour le prix, vous pourrez décider qu'il doit être présent dans le classe d'entités (future table de la BD) PRODUIT, mais aussi dans l'association entre PRODUIT et FACTURE pour en conserver l'historique : vous aurez alors deux rubriques différentes : "Prix courant" et "Prix facturé".
Voici un petit exemple de MCD avec le MLD et le code SQL correspondants :
Pièce jointe 588797
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 CREATE TABLE Client( Id_Client COUNTER, Nom VARCHAR(50), Adresse VARCHAR(80), CP CHAR(5), Ville VARCHAR(50), PRIMARY KEY(Id_Client) ); CREATE TABLE Facture( NumFac CHAR(8), DateF DATE, Id_Client INT NOT NULL, PRIMARY KEY(NumFac), FOREIGN KEY(Id_Client) REFERENCES Client(Id_Client) ); CREATE TABLE Produit( Réf CHAR(5), Libellé VARCHAR(50), Prix_courant CURRENCY, PRIMARY KEY(Réf) ); CREATE TABLE Contenir( NumFac CHAR(8), Réf CHAR(5), Qté SMALLINT, Prix_facturé CURRENCY, PRIMARY KEY(NumFac, Réf), FOREIGN KEY(NumFac) REFERENCES Facture(NumFac), FOREIGN KEY(Réf) REFERENCES Produit(Réf) );
Bonne continuation !

18/01/2021, 19h29
Sve@r

1 pièce(s) jointe(s)

Citation:

Envoyé par popo

Attention aux fausses idées reçues ou aux dogmes appliqués sans réfléchir.

Ce n'est pas une fausse idée, tyrtamos a vulgarisé ce que Merise a définit comme étant les 3 formes normales d'une bdd. Et effectivement cette forme normale implique un principe de "non redondance" ou comment positionner la donnée au plus juste. Bien sûr il y a parfois quelques impossibilités (ex la ville donne le code postal et le code postal donne la ville, souci référencé sous le vocable "Boyce-Codd") mais généralement on y arrive.
Et tyrtamos n'a jamais préconisé de faire ça "sans réfléchir". C'est justement en réfléchissant à la normalisation d'une bdd qu'on peut arriver à la faire coller au mieux au besoin.

Citation:

Envoyé par popo

La loi française implique donc de dupliquer l'information de l'adresse d'un client à plusieurs endroits... Donc conserver un historique des adresses (dont la majorité sont obsolètes)

Pas besoin d'historique. Suffit d'enregistrer l'adresse dans la table/relation associée à la facture elle-même.

Citation:

Envoyé par popo

Le dogme "Pas de redondance de données" est un bon principe mais il faut réfléchir à ce qu'on fait et ne pas l'appliquer à la lettre de manière systématique

Il faut savoir faire la part des choses. Si la facture doit mentionner une donnée particulière, donnée qui peut changer avec le le temps, alors la donnée datant de la facture doit-être recopiée dans la facture c'est évident. Cela ne remet pas en cause le principe de "non redondance" qui n'est là que pour éviter qu'une modification d'une donnée qui serait inutilement dupliquée dans deux tables B et C filles de A alors qu'elle aurait pu être unique dans A soit alors modifiée dans B mais pas dans C. Ce principe ne s'applique pas à ton exemple où ta facture a ici un rôle d'archive et ne sera pas impactée (surtout pas) par une modification de l'adresse.

Citation:

Envoyé par popo

Mais que fais-tu des prix des articles ?
Avec l'inflation, les prix des articles a augmenté.
Si je réédite la facture, je ne dois pas me retrouver avec les nouveaux prix mais bien avec ceux de l'époque.

J'ai eu ce souci dans un truc de gestion de commerce. Mes factures contenaient la référence du produit acheté, la qté achetée et une copie du prix de l'article au moment de l'achat. Et j'avais même pensé à une évolution possible de la TVA donc elle contenait aussi la TVA au moment de l'achat.
L'édition (réédition) de la facture utilisait la référence du produit pour afficher son libellé et les prix recopiés.
Et ma bdd gérait même l'historique des prix. Je pouvais donc faire des stats sur la variation du prix dans le temps. Et j'avais mis des triggers dans ma bdd pour que la modification du prix dans la table des articles soit automatiquement répercutée dans l'historique (c'était carrément le moteur bdd qui gérait) donc côté SQL, je faisais juste un simple "update".
Ci-dessous une copie d'écran (les prix ont été artificiellement générés ce qui explique les variations dans tous les sens)
Pièce jointe 588800
19/01/2021, 10h12
popo

Citation:

Envoyé par Sve@r

Ce n'est pas une fausse idée, tyrtamos a vulgarisé ce que Merise a définit comme étant les 3 formes normales d'une bdd. Et effectivement cette forme normale implique un principe de "non redondance" ou comment positionner la donnée au plus juste. Bien sûr il y a parfois quelques impossibilités (ex la ville donne le code postal et le code postal donne la ville, souci référencé sous le vocable "Boyce-Codd") mais généralement on y arrive.
Et tyrtamos n'a jamais préconisé de faire ça "sans réfléchir". C'est justement en réfléchissant à la normalisation d'une bdd qu'on peut arriver à la faire coller au mieux au besoin.

Citation:

Envoyé par tyrtamos

- on ne doit jamais avoir une même information à plusieurs endroits de la base de données, car le risque est qu'on mette à jour cette information à un seul endroit et pas dans tous, ce qui produirait une faute d'intégrité de la base. D'où les contraintes à créer entre les tables.

Je constate qu'on ne donne pas le même sens aux mots "on ne doit jamais".

Citation:

Envoyé par Sve@r

Il faut savoir faire la part des choses. Si la facture doit mentionner une donnée particulière, donnée qui peut changer avec le le temps, alors la donnée datant de la facture doit-être recopiée dans la facture c'est évident. Cela ne remet pas en cause le principe de "non redondance" qui n'est là que pour éviter qu'une modification d'une donnée qui serait inutilement dupliquée dans deux tables B et C filles de A alors qu'elle aurait pu être unique dans A soit alors modifiée dans B mais pas dans C. Ce principe ne s'applique pas à ton exemple où ta facture a ici un rôle d'archive et ne sera pas impactée (surtout pas) par une modification de l'adresse.

Tu ne fais que confirmer mon propos.
Le principe de non redondance ne s'applique pas dans ce cas précis et c'est justement là où je voulais en venir par "dogmes appliqués sans réfléchir".
19/01/2021, 14h27
Sve@r

Citation:

Envoyé par popo

Je constate qu'on ne donne pas le même sens aux mots "on ne doit jamais".

C'est le souci d'un forum dans lequel il manquera toujours l'intonation de la voie, la gestuelle et la réponse immédiate face à son interlocuteur si celui-ci ne réagit pas comme on l'espère. Si dans une discussion je dis "on ne doit jamais" et que l'autre répond "oui mais dans ce cas précis...", je pourrai de suite temporiser/minimiser/relativiser/préciser ; mais pas dans un forum dans lequel le lecteur doit alors faire confiance et "sentir" que si l'écrivain, qui de plus a une certaine notoriété en terme de points et de posts, a écrit "on ne doit jamais" c'était quand-même fortement sous-entendu "de façon générale et les cas particuliers devront être examinés au cas par cas".
20/01/2021, 12h23
popo

Citation:

Envoyé par Sve@r

C'est le souci d'un forum dans lequel il manquera toujours l'intonation de la voie, la gestuelle et la réponse immédiate face à son interlocuteur si celui-ci ne réagit pas comme on l'espère. Si dans une discussion je dis "on ne doit jamais" et que l'autre répond "oui mais dans ce cas précis...", je pourrai de suite temporiser/minimiser/relativiser/préciser ; mais pas dans un forum dans lequel le lecteur doit alors faire confiance

Citation:

Envoyé par Sve@r

et "sentir" que si l'écrivain, qui de plus a une certaine notoriété en terme de points et de posts, a écrit "on ne doit jamais" c'était quand-même fortement sous-entendu "de façon générale et les cas particuliers devront être examinés au cas par cas".

Je suis d'accord avec la première partie mais pas avec la seconde.
Le lecteur n'est pas dans la tête du rédacteur et ce qui peut paraitre évident pour le rédacteur ne l'est pas forcément sur le lecteur.
J'estime que justement, lorsqu'un expert s'adresse à un novice par écrit, il devrait avoir suffisamment d'expérience pour savoir éviter les radicaux qui pourraient être pris à la lettre.
Encore plus dans le monde du développement où une spécificité non explicitée par le demandeur au départ peut conduire à devoir récrire énormément de choses et retarder la livraison de manière plus ou moins importante.