Discussion :

[Fodchan]

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

[wiztricks]

Salut,

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

[fred1599]

Bonsoir,

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é !

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.

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 ?

[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!

[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:

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

[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 !

[Sve@r]

Bonjoir

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.

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

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.

[Invité]

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.
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)

[wiztricks]

Salut,

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

[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?

[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.

[wiztricks]

Salut,

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

[Sve@r]

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.

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 #5 de Fodchan qui veut tout apprendre tout de suite)...

[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

[fred1599]

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

[popo]

- 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

[wiztricks]

Salut,

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

[tyrtamos]

Bonjour,

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).

[popo]

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.

[wiztricks]

Salut,

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