Discussion :

[NABIL74]

Bonjour,
voilà, j'ai une ancienne application (gestion de biblio pour les livres de notre école) qui tourne depuis plus de 8 ans : Delphi 7 entr + paradox.
quand le nombre d'enregistrement est inférieur à 8000, l'application tourne bien (légère), mais comme ce nombre dépasse 9000, l'application devient lourde: le lancement de l'application prend plus de 20 secondes sans parler de la recherche(prend beaucoup de temps pour localiser l'enregistrement souhaité).

J'ai fait un test avec 65000 enregistrements, elle prend plus 40 s pour que l'application s'affiche...!!

J'ai un DataModule qui contient une vingtaines de requêtes de calcule (multiplication,...).
Au lancement de l'application, toutes les tables et toutes les requêtes sont ouvertes (propriété "Active" = true).

Comment faire pour que mon application soit légère même avec plus de 65000 enregistrements ?
Faut-il ouvrir certaines requêtes seulement au lancement de l'application?...

Merci pour votre aide.

Cordialement
Nabil

[free07]

Bonjour,

Est ce que tu utilises le BDE ? Concernant le BDE, il y a des paramètres qui peuvent être modifié ( par l'administrateur du BDE ) comme MEMSIZE, MAXFILESHANDLES et qui peuvent jouer sur les performances etc
Je te dis cela de mémoire car il y a longtemps que je n'utilises plus le BDE...

Pour ma part, je ne laisse pas les tables ouvertes si elles ne sont pas utilisées. C'est une règle que je me suis imposée et je n'ai jamais eu à m'en plaindre

Tu as beaucoup de tables ?

Ensuite il faut voir au niveau des requêtes, s'il n'y a pas d'optimisation à faire ( comme minimiser les SELECT *, ... )

[Paul TOTH]

1) paradox n'est pas une base SQL, c'est à mon avis une erreur d'utiliser SQL pour accéder à ces tables.

2) il manque probablement des index sur tes tables pour accélérer les choses.

[Paul TOTH]

Oui j'utilise le BDE comme moteur.
Il y a 12 tables et 22 requêtes dans lequelles on trouve le "select * " avec "order by".
Quand j'ouvre seulement les tables, l'application se lance sans aucune lourdeur, mais quand j'ouvre certaines requetes, on la sent cette lourdeur surtout au lancement de l'application.

c'est très probablement parce qu'i n'existe pas d'index reprenant les champs du ORDER BY, du coup le trie se fait à l'ouverture.

[NABIL74]

Paul,
j'ai la table principale qui contient une trentaine de champs dont il y a "num_livre" comme clé primaire et le champs "Titre_livre" comme index secondaire.
J'ai une requete :select *
From Livres.db
Order by num_livre
Elle prend plusieurs secondes pour qu'elle s'ouvre.

[Paul TOTH]

quels type de champs possède-t-elle ?

j'ai pour habitude de ne faire que des indexes uniques, donc l'indexe secondaire devrait être "Titre_livre, num_livre", mais je ne pense pas que cela affecte les performances.

qu'est ce que cela donne si tu remplaces ton Query par un TTable ? si tu supprimes le Order By (ou ne spécifie pas d'index dans le TTable) est-ce aussi lent ?

[NABIL74]

Le champ: "num_livre " est de type integer.
Le champ: "titre_livre " est de type String.
Ce soir , quand je rentrerai chez moi, je testerai ce que tu m'as demandé et je te dirai...
A+

[ShaiLeTroll]

9000 enregistrements, ça devient lourd ???
Avec paradox, j'ai eu des tables de 200 000 enregistrements, et là c'était vraiment lent avec une table de 500Mo (db, px, py, mmo confondu)

Code sql :

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

1
2
3
select * 
 From Livres.db
 Order by num_livre

Evite de faire du SELECT * FROM sans WHERE ! sur Paradox, cela ne fonctionne pas bien du tout !
C'est bien le seul cas où je conseille d'utiliser des TTable surtout si ton module est mode local et exclusif
Si tu fais du client multiple, le TTable c'est déjà moins bien ( voir PdxUser.Net ), tu auras des problèmes de Lock entre tes modules qui font du TQuery et TTable

Lorsque tu fais un SELECT débrouille toi pour qu'il soit le résultat soit le plus petit possible (genre moins de 100 lignes)
Ne jamais chargé la DB entière

Ajoute des index primaire et secondaire, c'est indispensable

Un simple TTable IndexFieldName et Open sera bien plus performant pour lire Livres.db
Encore mieux si num_livre est le champ autoinc en index primaire !

Le TTable ne charge pas les données complètement, il lit que ce qui est nécessaire, c'est le BDE qui fait cela !
Il utilise l'index px/py pour savoir quoi lire dans le fichier db

Evidemment charger 65000 enregistrements est un non-sens total dès le démarrage du programme
Sur un SGBD réseau c'est provoquait une consommation mémoire sur le serveur, une consommation de la bande passante du réseau, ...

Je n'ai pas fait de Paradox en utilisation IHM depuis 2001
L'application pouvait supporter 7 utilisateurs simultanés mais c'était peu stable mon chef de projet de l'époque (même mon maitre de stage) a limité volontairement trois utilisateurs mais cela venait du FileSystem de Win95/98
Il y a des experts Paradox qui sont montés bien plus loin aussi bien en connexion simultané qu'en volumétrie

Cherche sur le forum Paradox + PdxUser.Net et aussi Paradox + Samba
Très utile si tu as aussi besoin d'un accès concurrentiel sur Paradox

J'ai utilisé Paradox en table de travail local en mode exclusive en 2003, c'est dans ce cas où j'ai lorsque le locate dépassait les 200ms que cela m'a posé problème pour mon projet ou je devais avoir des temps de réponse inférieur à 250ms pour le traitement globale (ce locate n'était que 10% du traitement)
J'ai utilisé un technique que j'avais vu chez mon premier employeur pour gérer les catalogues d'appareils médicaux, l'utilisateur créait sa liste de favori (en général les praticien sons fidèles à une ou deux marques)
Dans mon cas, une phase préparatoire faisait une extraction dans le catalogue complet vers un catalogue utile, en général, cela me divisait par 10 le volumes

[NABIL74]

quels type de champs possède-t-elle ?

j'ai pour habitude de ne faire que des indexes uniques, donc l'indexe secondaire devrait être "Titre_livre, num_livre", mais je ne pense pas que cela affecte les performances.

qu'est ce que cela donne si tu remplaces ton Query par un TTable ? si tu supprimes le Order By (ou ne spécifie pas d'index dans le TTable) est-ce aussi lent ?

Bonsoir,

@ Paul,

Le champs "num_livre" est une clé primaire : l'utilisateur saisit le numéro du livre.
Le champs "Titre_livre" est un index secondaire.
Sans le Order By ou quand ne pas spécifier d'index dans le TTable c'est toujours aussi aussi lent.

1-
J'ai pu trouver les Query qui causent la lenteur du programme. Voici leur SQL:

Code :

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

1
2
select  *
from livres,ecole

2- Pour avoir la liste des titres des livres qui possèdent deux tomes ou plus .

Code :

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

1
2
3
4
Select Nom_livre,Count(*)
From Livres
GROUP  BY Nom_livre
HAVING COUNT(*) >=2

3-

Code :

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

1
2
3
Select Nom_livre,Source,Date_achat,COUNT( * ) COUNTALL
From Livres
Group By Nom_livre,Source,Date_achat

4-

Code :

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

1
2
3
4
Select Date_emprunte, Count(emprunte)
From Livres
Where (emprunte=true)and(Genre_emprunte='Externe')
Group By Date_emprunte

Peut-on les optimiser?

@ ShaiLeTroll

Evite de faire du SELECT * FROM sans WHERE ! sur Paradox, cela ne fonctionne pas bien du tout !
C'est bien le seul cas où je conseille d'utiliser des TTable surtout si ton module est mode local et exclusif
Si tu fais du client multiple, le TTable c'est déjà moins bien ( voir PdxUser.Net ), tu auras des problèmes de Lock entre tes modules qui font du TQuery et TTable

Merci pour tes conseils.
Avec 65000 enregistrements, la taille de la table Livres dépasse 190 mo.

Mon module est mode local car l'application est utilisée dans la bibliothèque de notre école.
je me souviendrai du SELECT * FROM sans WHERE dans mes prochaines applications.

Evidemment charger 65000 enregistrements est un non-sens total dès le démarrage du programme
Sur un SGBD réseau c'est provoquait une consommation mémoire sur le serveur, une consommation de la bande passante du réseau, ...

je suis obligé de charger tout les enregistrements au démarrage de l'application car ils représentent les titres des livres qui sont dans la bibliothèque.

A+
NABIL

[SergioMaster]

Bonjour,

je suis obligé de charger tout les enregistrements au démarrage de l'application car ils représentent les titres des livres qui sont dans la bibliothèque.

obligé ? je ne crois pas , même une grille ne peut contenir 65000 enregistrements sur l'écran


Constations : les requêtes qui sont lentes sont soit des requêtes de groupage soit des jonctions de tables (écrites soit dit en passant à l'ancienne mode => non normalisée)

ma suggestion principale : migrer vers un SGBD plus costaud et en même temps (pas obligatoire mais certainement adéquat oublier le BDE)
Comment : utiliser (par exemple pour ceux qui n'ont pas de moyen) Firebird et ZEOSDBO et migrer les données en conséquence
avantage de la solution citée :
- peu de modification dans le programme (remplacement de type de composants TTable-> ZTable, TQuery -> TZQuery, TDataBase -> TZConnection
- ZTable comme ZQuery permettent de moduler le nombre d'enregistrements à envoyer sans avoir à s'en soucier pour lire la suite
- Abandon du BDE
- SGBD récent pouvant utiliser l'Unicode au besoin

Ainsi, cerise sur le gâteau, l'application pourrait même devenir réseau !

Resterai cependant à normaliser un peu plus le SQL

Code :

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

1
2
select  *
from livres,ecole

Code :

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

1
2
3
deviendrait 
SELECT * << ici il vaut mieux indiquer les champs voulu
FROM livres NATURAL JOIN ecole  << ici il vaudrait mieux indiquer sur quels critères se fait la jonction plutôt que NATURAL

pour plus d'informations se renseigner sur les jointures (même paradox connait, bien que peu évoluées)

Je sais que cela ne constitue pas vraiment une réponse et mériterais presque un Hors Sujet mais c'est mon opinion

[Paul TOTH]

[QUOTE=NABIL74;8391520]

Code :

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

1
2
select  *
from livres,ecole

c'est supposé retourner quoi ?

Code :

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

1
2
3
4
Select Nom_livre,Count(*)
From Livres
GROUP  BY Nom_livre
HAVING COUNT(*) >=2

c'est pour trouver les doublons ?

Code :

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

1
2
3
Select Nom_livre,Source,Date_achat,COUNT( * ) COUNTALL
From Livres
Group By Nom_livre,Source,Date_achat

je commence à avoir de sérieux doutes sur la structure de tes tables

Code :

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

1
2
3
4
Select Date_emprunte, Count(emprunte)
From Livres
Where (emprunte=true)and(Genre_emprunte='Externe')
Group By Date_emprunte

j'ai comme l'impression que la table Livres fonctionne comme une feuille Excel et non comme un base de données !

la table Livres ne devrait contenir qu'une seule référence à chaque ouvrage identifié par un ISBN
à côté une table Emprunts donnerait le détail des emprunts en faisant référence au Num_Livre, et à une table Clients avec un Num_Client

as-tu des notions de relation maître/détail ?

[NABIL74]

@ Serge,
Merci pour tes conseils!
Oui, je dois migrer mon application vers un Sgbd plus performant et plus récent comme Firebird qui me convient bien.

En 2002-2003 je commencais à faire mes premiers pas dans la programmation sous Delphi 5 et 6. J'ignorais beaucoup de choses, je me posait toujours la question: comment faire ça? Comment faire une relation maitre_détail?...
Durant ce temps, beaucoup de développeurs font leurs BD sous paradox.
Et ma premiére application était la gestion de la bibliothèque de notre école, pour la gestion de l'inventaire,les emprunts,... Excusez les "choses bizzares" que vous avez remarqué.

@ Paul,
"select *
from livres,ecole"

C'est pour l'état de l'impression qui comporte tous les champs de la table "Livres"et le nom de l'école et celui de l'académie.

2-
[Select Nom_livre,Count(*)
From Livres
GROUP BY Nom_livre
HAVING COUNT(*) >=2]

C'est pour avoir la liste des livres qui possèdent deux tomes et plus: on filtre les livres qui ont 2 tomes et plus.s'il y en a un qui n'a pas de tome, on l'ignore.
Exemple:
-"Sciences naturelles" => 4 tomes.(oui)
-"Les misérables" => un seul tome(non, on l'ignore.

3-
[Select Nom_livre,Source,Date_achat,COUNT( * ) COUNTALL
From Livres
Group By Nom_livre,Source,Date_achat]

C'est pour savoir le nombre chaque de chaque livre. Exemple:
- "Sciences naturelles" ( 10 exemplaires)
-"Les misérables" (5 exemplaires).
...
...
...
Il faut refaire la structure des tables,
avoir les tables :"Livres" , "Emprunts", "Historique" ,... En plus de migrer vers un SGBD comme Firebird ou autre.

J'ai fait de petite application avec Firebird avec la version embarquée il y a plus de 6 ans, et depuis ce temps,je n'ai pas travaillé avec. j'ai oublié beaucoup de choses.
Quel SGBD me conseillez-vous? Firebird, Maria DB, Absolute Database...?

Merci pour vos remarques et pour vos conseils.

[SergioMaster]

Bonjour,

J'ai fait de petite application avec Firebird avec la version embarquée .... j'ai oublié beaucoup de choses.
Quel SGBD me conseillez-vous? Firebird, Maria DB, Absolute Database...?

mes conseils n'engagent que moi, à mon avis déjà cela va dépendre de plusieurs facteurs :
* Les moyens
- la version de Delphi disponible
- la maitrise des SGBD cités
* l'avenir
- l'objectif (rester sur une application mono-poste ou évoluer/prévoir la possibilité de) et l'environnement (utilisation d'internet par exemple)
- les délais

Ayant déjà un existant (tables paradox) et le programme moi je conseillerai de migrer vers Firebird (il existe des outils) cependant un travail de modélisation de la base de données risque d'être à faire (avant ou par la suite). Si j'avais cité ZEOS+Firebird+Delphi 7 c'est que j'ai déjà fait ce genre de migration BDE->ZEOS pour certains de mes vieux programmes (nota la base était déjà en place). Il est vrai que depuis j'ai repris/je refait l'application et que ma programmation à changé (plus de Querys moins de Tables par exemple , plus de jointures aussi et donc moins de champs liés via dataset), la ré-écriture fait que, excepté l'IHM peut modifié pour cause d'habitudes utilisateurs, le code lui est plus compact et plus stable je pense (espère )

Il est vrai qu'une base noSQL pour une bibliothèque pourrait être intéressante mais tu "attaquerais" cette base avec quels composants ?
Le choix d'une SGBD est complexe mais si on enlève les SGBD commerciales il se réduit , si à la suite on applique le filtre Delphi (les composants utilisables) et le filtre maitrise personnelle .....

[NABIL74]

Bonjour,

mes conseils n'engagent que moi, à mon avis déjà cela va dépendre de plusieurs facteurs :
* Les moyens
- la version de Delphi disponible
- la maitrise des SGBD cités
* l'avenir
- l'objectif (rester sur une application mono-poste ou évoluer/prévoir la possibilité de) et l'environnement (utilisation d'internet par exemple)
- les délais

Bonsoir,

oui, tout à fait avec ton avis.
J'ai beaucoup travaillé avec Delphi 7 + Paradox, des fois avec Absolute DataBase(commercial, SGBD Fichier mais sans passer par le BDE).
Maintenant, j'ai toujours mon Delphi 7 et Delphi XE 5. Les moyens y sont, il faut avoir la volonté de laisser tomber( l'utilisation du BDE) et évoluer vers un SGBD plus performant donc il faut que je change l'habitude de travailler dorénavant.

Pour le choix du SGBD, Firebird me convient bien en plus il y a des outils gratuits qui vont avec.

Je me souviens bien lors de la première utilisation de Firebird, je n'ai pas trouvé le type de champ autoinc, j'ai bien cherché mais rien! On m'a dit par la suite qu'il faut créer une procedure ou un trigger

Merci pour vos précieux conseils.

Bonne soirée.

[SergioMaster]

Avec Delphi 7 mon choix se porterait sur le ZEOSDBO set de composants très semblable à ceux de BDE (voir dans mon blog pour un début de tutoriel)
Avec XE5 ma foi Firedac est envisageable

Pour ce qui est de l'autonumerotation avec Firebird c'est relativement simple il existe les générateurs (aussi nommé séquence) et oui, un trigger sur un Insert permet de faire le travail si le numéro n'est pas renseigné mais il y a aussi d'autres manières (via composant avec ZEOS et Firedac ou via SQL)

[Paul TOTH]

avant d'envisager le changement de bdd il me semble plus important de changer la structure des tables qui n'est pas optimale.

de façon générale, il faut éviter les redondances.

notamment tout ce qui est GROUP BY Nom_Livre devrait faire référence à un champ index.

au lieu d'avoir dans la même table Nom_Livre, Source, Date_Achat, ce qui provoque forcément des doublons

on a une table Livres avec Num_Livre, Nom_Livre où chaque livre n’apparaît qu'une seule fois, et une table Achats avec Num_Livre, Source, Date_Achat. Je ne sais pas ce que c'est que "Source" mais ça peut aussi être une table avec une clé de référence.

Après, bien que ce ne soit pas forcément recommandé, je place parfois un champ calculé dans mes tables. Exemple, Livres pourrait contenir un champ Nombre_Exemplaires qui sera mis à jour à chaque insertion/suppression dans la table des Achats. Dès lors la requêtes sur le nombre d'exemplaires devient immédiate : "SELECT Nom_Livres, Nombre_Exemplaires FROM Livres ORDER BY Nom_Livres, Num_Livre"

rien qu'en faisant cela la taille de la base va fondre car on évite les redondances sur le champ Nom_Livre pour ne garder que des Num_Livre.

de la même façon on ne mettre pas un champ Nom_Auteur dans la table des livres, mais un Num_Auteur qui fait référence à la table Auteurs, où chaque auteur n'apparaît qu'une fois.

[SergioMaster]

Bonjour,

je suis d'accord avec Paul lorsqu'il parle de restructurer les tables, j'ai vu un modèle assez complet de gestion de bibliothèque dans un tutoriel cependant je n'arrive pas à remettre la main dessus.

pour ce qui est de la query n°1 select * from livres,ecole je n'avais été choqué que par le * (il faut toujours donner les champs que l'on veut) et par le forme non normalisée de la jointure (, plutôt que JOIN) je n'avais pas fait attention au fait que même non normalisée il n'y avait aucune indication de la jointure entre les deux tables , le "pas de clause WHERE" de ShaiLeTroll et ça c'est pas bon du tout ! et surtout le résultat est certainement faux

comment s'en rendre compte ?
un simple petit exemple avec une table livres et une table écoles
un seul livre dans la table livres (un identifiant et un code école) et par contre 3 écoles (identifiant différents)

Livres
id=1, titre='livre 1', idecole=2
Ecoles
idecole=1,nom='ecole 1'
idecole=2,nom='ecole 2'
idecole=3,nom='ecole 3'

malgré une notification d'intégrité référentielle (livres.idecole ecoles.idecole) je vais obtenir 3 enregistrements ! au lieu du seul enregistrement souhaité:

id=1,titre='livre1',idecole=2,idecole=2,nom='ecole 2'

au passage à noter que l'on obtient 2 fois l'idecole !

pour obtenir le résultat certainement attendu il aurait fallu écrire
au pire SELECT * from livres,ecoles WHERE livres.idecole=ecoles.idecole
en appliquant les normes (pas si nouvelles que ça )

Code :

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

SELECT idLivre,titre,idecole,nom from livres join ecoles on (livres.idecole=ecoles.idecole)

mais cela n'est pas encore suffisant, le "idecole" de l'ensemble résultat est ambigu (est-ce celui de livres ou celui de ecoles ?)

pour cela on va utiliser des alias de tables, plus facile que d'avoir à répéter chaque fois le nom

Code :

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

SELECT l.idLivre,l.titre,l.idecole,e.nom from livres l join ecoles e on l.idecole=e.idecole

s'approcherait-on de la perfection ,pas dans la structure des tables, mais dans la requête ? presque on en arrive aux spécificités de Paradox dont le moteur utilise le QBE (soit la requête par l'exemple) et qui va fournir une table de réponse triée sur tous les champs ( si si fais l'essai en QBE si tu ne me crois pas !)
bref il va falloir rajouter une clause ORDER BY pour éviter ça

ce qui donne par exemple :

Code :

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

SELECT l.idLivre,l.titre,l.idecole,e.nom from livres l join ecoles e on l.idecole=e.idecole ORDER BY l.titre,l.idlivre

Oui mais du coup pourquoi ai-je mis le titre(qui suffirai) et l'id du livre dans l'ordre de tri ? (j'aurais aussi pu rajouter l'idecole)
à priori tu nous a indiqué que l'on pouvait avoir plusieurs fois le même titre et ce à fortiori dans une même école (ce qui semblerai logique si on gère les manuels scolaires par exemple)

Ouf, aurait-on enfin fini ? presque si ce n'est qu'il va falloir ajouter un index sur le nom de la table livres ce qui sera un plus pour le tri (pour l'idecole en fait il y en a déjà un de créé à cause de l'intégrité référentielle)

[NABIL74]

avant d'envisager le changement de bdd il me semble plus important de changer la structure des tables qui n'est pas optimale.

de façon générale, il faut éviter les redondances.

notamment tout ce qui est GROUP BY Nom_Livre devrait faire référence à un champ index.

au lieu d'avoir dans la même table Nom_Livre, Source, Date_Achat, ce qui provoque forcément des doublons

on a une table Livres avec Num_Livre, Nom_Livre où chaque livre n’apparaît qu'une seule fois, et une table Achats avec Num_Livre, Source, Date_Achat. Je ne sais pas ce que c'est que "Source" mais ça peut aussi être une table avec une clé de référence.

Bonsoir à tous,

Merci pour vos précieux conseils et pour vos remarques.

@ Paul,

Bien vu! Oui comme je l'ai déjà dit, je dois commencer à restructurer toute la BD et puis coder ça en utilisant FireBird comme SGBD.

Paul, Dans notre Bilbio de l'école, chaque livre possède un numéro (Num_Livre) et un numéro de l'inventaire ("Num_inventaire" ), donc la table "Livres" aura forcément des doublons de "Nom_Livre". Quand un élève emprunte un livre, on mentionne son nom et prénom, sa classe, le numéro du livre ,le numéro de l'inventaire et la date de l'emprunte.
Le directeur fait l'inventaire de la bilio plusieurs fois dans l'année et il aura toujours besoin du numéro de l'inventaire de chaque livre emprunté.
Le champ "Source" signifie que le livre est-il acheté par l'école, un don, ou offert par l'académie de l'éducation.

de la même façon on ne mettre pas un champ Nom_Auteur dans la table des livres, mais un Num_Auteur qui fait référence à la table Auteurs, où chaque auteur n'apparaît qu'une fois.

Oui et non Paul. Un livre peut avoir deux ou trois auteurs. je t'explique:
- un livre intitulé "La faune et la flore" son auteur nommé : Serge
- un livre intitulé "La faune et la flore" son auteur nommé : Nabil
- un livre intitulé "La faune et la flore" son auteur nommé : Paul
Le contenu de chaque livre diffère de l'autre.

@ Serge,
Je suis tout à fait avec ton raisonnement.
Merci pour ton aide!
Tu es très fort en SQL et dans l'analyse de BD, Chapeau!

Qu'est-ce que vous me conseillez pour les composants d'accès aux données avec Firebird : "FIBplus" ou "ZEOSDBO" ?

Merci pour votre aide tout les deux.
Toujours vous êtes disponible à aider les autres.
Merci encore.

Bonne soirée.

[SergioMaster]

Bonjour,

Tu es très fort en SQL et dans l'analyse de BD, Chapeau!

loin de là, c'est uniquement l'expérience et les tests qui me font donner les réponses que je crois correctes

Qu'est-ce que vous me conseillez pour les composants d'accès aux données avec Firebird : "FIBplus" ou "ZEOSDBO" ?

c'est avant tout un choix de budget FIBPlus = 235 €, ZeosDBO = 0e et avec les sources qui plus est
ensuite un choix de maintenance, je croyais FIBPlus moribond pas de nouvelles depuis 2013 (annonce FibPlus pour XE4)

un point pour FibPlus (ou IBDac moins cher d'ailleurs 100€) c'est que l'objectif est purement Firebird
mais c'est aussi par la même peut être un point négatif si l'on veut pouvoir travailler sur un SGBD différent

points pour ZeosDBO, malgré qu'il soit plus "lourd" en code , on a les sources (et donc on peut réduire le champ des possibilités SGBD ce qui le rend moins "lourd"). Par contre peu de documentation, toute la documentation des composants BDE peut malgré tout s'appliquer, et mon tutoriel, je n'en ai pas repris l'écriture depuis un an la faute à Firedac (ex Unidac) fourni maintenant avec Delphi. Le BDELike reste malgré tout un point positif pour ce qui est d'une migration et des compétences (il n'y a pas trop à (ré)apprendre) au cas où tu n'aurais pas vu mon ébauche de tutoriel en voici le lien/

ce que je ferais moi (d'expérience car je maintiens une application D3+BDE+Firebird)
a) une migration "légère" : Delphi7 avec changement de BDE vers ZeosDBO + Firebird afin que l'application puisse continuer à tourner sur le programme existant
b) une grosse remise en question de la structure de la bdd
c) une ré-écriture plus 'moderne' au niveau IHM (dans mon cas XE10 FMX+ Firedac) , plus orienté Base de Données (requêtes, trafic réseau et ce même si c'est une application monoposte) etc... comme la structure aura certainement changé et comme cela prendra du temps c'est pour cela que j'ai mis la partie a)

[Paul TOTH]

Paul, Dans notre Bilbio de l'école, chaque livre possède un numéro (Num_Livre) et un numéro de l'inventaire ("Num_inventaire" ), donc la table "Livres" aura forcément des doublons de "Nom_Livre". Quand un élève emprunte un livre, on mentionne son nom et prénom, sa classe, le numéro du livre ,le numéro de l'inventaire et la date de l'emprunte.
Le directeur fait l'inventaire de la bilio plusieurs fois dans l'année et il aura toujours besoin du numéro de l'inventaire de chaque livre emprunté.
Le champ "Source" signifie que le livre est-il acheté par l'école, un don, ou offert par l'académie de l'éducation.

Oui et non Paul. Un livre peut avoir deux ou trois auteurs. je t'explique:
- un livre intitulé "La faune et la flore" son auteur nommé : Serge
- un livre intitulé "La faune et la flore" son auteur nommé : Nabil
- un livre intitulé "La faune et la flore" son auteur nommé : Paul
Le contenu de chaque livre diffère de l'autre.

on ne fait pas de doublon dans une bdd à chaque fois qu'une information est en double elle peut être placée dans une table annexe.

Table Livre:
Num_Livre
Nom_Livre

exemple:
1 "La faune et la flore"

Table Inventaire:
Num_Inventaire
Num_Livre -> Livres
Source

exemple:
1, 1, "Don"
2, 1, "Achat"

Table Auteurs
Num_Auteur
Nom_Auteur

exemple:
1, "Serge"
2, "Nabil"
3, "Paul"

Table AuteursLivre
Num_Auteur -> Auteurs
Num_Livre -> Livres

exemple:
1, 1
2, 1
3, 1

Table Emprunts
Num_Emprunt
Num_Inventaire -> Inventaires
Num_Eleve -> Eleves
Date_Emprunt
Rendu_Le

Table Eleves
Num_Eleve
Nom_Eleve
Num_Classe -> Classes

exemple
1, 'Paul', 1

Table Classes
Num_Classe
Nom_Classe

1, 'CP'
2, 'CM1'

avec ça, si je veux connaitre tous les livres de l'auteur Server
SELECT li.Nom_Livre
FROM Livres li
JOIN AuteursLivre al ON al.Num_Livre= li.Num_Livre
WHERE al.Num_Auteur = 1

si je veux tous les livres empruntés par un élève de CP
SELECT Nom_Livre, iv.Num_Inventaire
FROM Livres li
JOIN Inventaire iv ON iv.Num_Livre = li.Num_Livre
JOIN Enprumpts en ON en.Num_Inventaire = li.Num_Inventaire
JOIN Eleves el ON el.Num_Eleve = en.Num_Eleve
WHERE el.Num_Class = 1

et si demain Paul passe en CM1, il suffit de mettre à jour la table Eleves (UPDATE Eleves SET Num_Classe = 2 WHERE Num_Eleve = 1) et tous les livres qu'il a emprunté sont automatiquement passé en CM1 également (sauf si on veux se rappeler qu'il était en CP au moment du prêt, mais dans ce cas on stocke l'information dans la table Emprunt car ce n'est plus la classe de l'élève mais la classe dans laquelle il était au moment de l'emprunt, et là aussi on gardera un Num_Class et non pas le nom de la classe)