Discussion :

[bash.net]

Bonjour,

Que peut-on faire quand le nombre maximum de 32768 tables de Firebird a été atteint ?

C'est nul de limiter le nombre de tables alors qu'une base de données peut atteindre 128 TB.
Tout le monde sait que pour optimiser les recherches SQL il est préférable d'avoir plusieurs petites tables plutôt que de très grandes tables.

Je gère dans Firebird toutes les données RH d'une entreprise avec ses 40 filiales.

Peut-on joindre deux fichiers de bases de données Firebird ?
Migration vers MySQL qui ne comporte pas de limite de tables ?

Merci de vos aides et conseils.

[SergioMaster]

Bonjour et bienvenue,

32768 tables ! Perso je n'ai jamais atteint de chiffre d'un autre côté j'ai tendance à utiliser plusieurs bases puisque l'on peut faire des interrogations croisées.

Tout le monde sait que pour optimiser les recherches SQL il est préférable d'avoir plusieurs petites tables plutôt que de très grandes tables.

là il y a peut-être quand même des limites, je commence toujours par une bonne indexation

Peut-on joindre deux fichiers de bases de données Firebird ?

avec ON EXTERNAL DATA SOURCE au sein de procédures exemple :

Code :

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

1
2
3
4
5
6
7
execute block returns (emp_no smallint) as
begin
FOR EXECUTE STATEMENT 'select emp_no from employee'
ON EXTERNAL DATA SOURCE 'localhost:employee' AS USER 'sysdba' PASSWORD 'masterkey'
INTO :emp_no
DO SUSPEND;
end

et il y a aussi les possibilités de tables externes

Avant de songer à MySQL il faut en lire ses critiques (pas toujours objectives) de Fréderic Brouard aka SQLPro à rechercher dans le forum SGBD si mes souvenirs sont bons, lors des annonces de sorties de versions.
Mais, là aussi, mon objectivité peut être mise en cause

[escartefigue]

Bonjour,

Tout le monde sait que pour optimiser les recherches SQL il est préférable d'avoir plusieurs petites tables plutôt que de très grandes tables.

Si par très grande on veut dire à forte cardinalité, alors non : une table contenant un très grand nombre de lignes peut être très performante si elle est indexée comme il faut avec un bon facteur de filtrage.
De plus, dupliquer une table à l'identique pour en découper l'effectif est une très mauvaise solution, il est préférable de la partitionner.
Si par très grande on veut dire avec un très grand nombre de colonnes, alors là, d'accord, ce type de tables, dites "tables obèses" est une véritable hérésie à tout point de vue, pas seulement concernant les perfs, mais aussi l'intégrité et la fiabilité des données et les accès concurrents dégradés.

Migration vers MySQL qui ne comporte pas de limite de tables ?

Sauf que MySQL confond base de données et schémas, là aussi c'est une véritable hérésie lourde de conséquences en matière d'urbanisation !

[bash.net]

Si par très grande on veut dire à forte cardinalité, alors non : une table contenant un très grand nombre de lignes peut être très performante si elle est indexée comme il faut avec un bon facteur de filtrage.
De plus, dupliquer une table à l'identique pour en découper l'effectif est une très mauvaise solution, il est préférable de la partitionner.
Si par très grande on veut dire avec un très grand nombre de colonnes, alors là, d'accord, ce type de tables, dites "tables obèses" sont une véritable hérésie à tout point de vue, pas seulement concernant les perfs, mais aussi l'intégrité et la fiabilité des données et les accès concurrents dégradés.

Merci pour votre réponse.

Le problème de performance d'une base de données provient généralement des filtres qui prennent du temps à s’exécuter. Le temps CPU pour exécuter un filtre SQL est équivalent à un filtre qu'on ferait avec une boucle FOR pour tester si chaque champs doit être filtré ou non. Donc si il y a beaucoup d'enregistrements le filtre prendra forcément plus de temps.
Notre structure de la base de données a été pensée pour que les recherches SQL soient instantanées, qu'elles soient exécutées en intranet, en extranet ou depuis internet. En limitant les filtres on gagne énormément en performance, mais c'est au prix d'un nombre de tables importants. Il y a toujours une contrainte quelque part quand on cherche à optimiser.
Il n'y a pas de duplication ou de redondance de données dans notre structure, juste un découpage des données très optimisé.


Si vous me dite que MySQL n'est pas forcément la solution, j'aurais alors besoin d'exporter certaines tables vers une autre base de données pour passer la contrainte du nombre de tables.

[bash.net]

Bonjour et bienvenue,

32768 tables ! Perso je n'ai jamais atteint de chiffre d'un autre côté j'ai tendance à utiliser plusieurs bases puisque l'on peut faire des interrogations croisées.


là il y a peut-être quand même des limites, je commence toujours par une bonne indexation


avec ON EXTERNAL DATA SOURCE au sein de procédures exemple :

Code :

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

1
2
3
4
5
6
7
execute block returns (emp_no smallint) as
begin
FOR EXECUTE STATEMENT 'select emp_no from employee'
ON EXTERNAL DATA SOURCE 'localhost:employee' AS USER 'sysdba' PASSWORD 'masterkey'
INTO :emp_no
DO SUSPEND;
end

et il y a aussi les possibilités de tables externes

J'utilise C++ builder et je pensais utiliser un autre composant TFDConnection afin d'être connecté sur deux bases de données différentes et ajouter les enregistrements dans les tables en fonction de là où elles se trouvent. Qu'en pensez-vous ?

[SergioMaster]

Quel que soit le langage utilisé (Delphi ou C++) bien sûr que deux FDConnections sont possibles quoique je ne comprenne pas bien ce qui est voulu ?
S'il s'agit d'interroger deux bases différentes, pas de souci, s'il s'agit de fusionner dans une liste (genre grille) non un "TDatasource" ne prendra jamais les deux bases de données.

Cependant, Firedac propose un truc intéressant si l'on ne veut pas faire le travail en amont sur le serveur de bases de données (via ON EXTERNAL DATASOURCE de Firebird) il s'agit des tables mémoires (FDmemtable) et des requêtes locales (FDLocalSQL) mais cela déborde totalement de ce forum puisqu'il s'agit dans ce cas de langage ou plutôt de composants proposés par Embarcadero. Perso, j'ai tendance à faire faire le boulot par le serveur pas par un poste client, que ce soit dans le cadre d'une application client-serveur ou multi-tiers.

A propos j'ai lu ceci récemment roadmap Firebird 6 qui correspond peut-être à votre cas (partie tablespaces) mais la description n'en est pas assez claire pour une visualisation précise de ma part.

[Michel.Priori]

Le problème de performance d'une base de données provient généralement des filtres qui prennent du temps à s’exécuter. Le temps CPU pour exécuter un filtre SQL est équivalent à un filtre qu'on ferait avec une boucle FOR pour tester si chaque champs doit être filtré ou non. Donc si il y a beaucoup d'enregistrements le filtre prendra forcément plus de temps.
[...] En limitant les filtres on gagne énormément en performance, mais c'est au prix d'un nombre de tables importants. Il y a toujours une contrainte quelque part quand on cherche à optimiser.
Il n'y a pas de duplication ou de redondance de données dans notre structure, juste un découpage des données très optimisé.

Sérieux ?
Tu penses vraiment que les SGBD, qui sont des moteurs spécialisés dans la gestion de la donnée, seraient passé à coté du problème ?

Dans ton cas, vu que ton code prend les devants des problèmes potentiels de perf, je te suggère de te passer purement et simplement d'un SGBD.
Une gestion de fichiers suffit.
Vu que tu sais quel fichier ouvrir et parcourir intégralement, à quoi te sert un SGBD ?

[escartefigue]

Le problème de performance d'une base de données provient généralement des filtres qui prennent du temps à s’exécuter. Le temps CPU pour exécuter un filtre SQL est équivalent à un filtre qu'on ferait avec une boucle FOR pour tester si chaque champs doit être filtré ou non. Donc si il y a beaucoup d'enregistrements le filtre prendra forcément plus de temps.

Les restrictions ou "filtres" ne sont pénalisantes que si elles ne sont pas "SArgAble" c'est à dire s'il n'y a pas d'index filtrant applicable.
Une recherche sargable utilisera des index pour ne parcourir qu'un très petit sous ensemble des lignes des tables, alors qu'une recherche non fitrante devra parfois passer par des table scan.
Le cas typique de recherche non sargable est l'utilisation de l'opérateur "différent de", qui, pour être vérifié, requiert un parcours séquentiel de toutes les lignes, mais, s'il est associé à d'autres restrictions qui permettent de limiter la recherche, ce parcours séquentiel ne s'appliquera qu'au sous-ensemble matérialisé par les autres restrictions.
Quoi qu'il en soit, rien à voir avec une boucle "FOR" d'un traitement, une requête bien conçue est ensembliste, donc sauf à parcourir les lignes d'un curseur une à une, on est loin de la logique d'une boucle.

[SQLpro]

Tout le monde sait que pour optimiser les recherches SQL il est préférable d'avoir plusieurs petites tables plutôt que de très grandes tables.

Petite en degré (c'est à dire en nombre de colonne) pas en cardinalité.

• Avec un SGBD R base de gamme comme MySQL / Maria DB / FireBird, quelques dizaines de millions de ligne ne sont pas un problème si bien indexées.
• Avec un SGBD R moyenne gamme qui gère un partitionnement efficace (par exemple SQL Server en version Web ou Standard) et de la compression de données, on peut aller au milliard de lignes sans trop de problème
• Avec un SGBD R haut de gamme qui gères du stockage vertical ou vectoriel, on peut aller à des centaines de milliards de ligne sans problème...

Malheureusement FireBird n'a ni compression des données, ni partitionnement, ni stockage vertical ni vectoriel...

De plus la sécurisation pour du RH nécessite au minimum un chiffrement des bases de données du fait de la présence de données personnelles => Transparent Data Encryption si vous voulez à la fois des performances et du chiffrement afin que le vol de vos données ne soit pas revendu en place publique (ce qui vous coutera en sus des dégâts une amende de la CNIL si vous êtes attaqués...

A +

[SergioMaster]

Je me doutais que tu passerais par là. étonnant que tu n'aies pas relevé la partie MySQL

Malheureusement FireBird n'a ni compression des données, ni partitionnement, ni stockage vertical ni vectoriel...

De plus la sécurisation pour du RH nécessite au minimum un chiffrement des bases de données

Beaucoup de choses changent, le chiffrement existe de façon plus simple depuis la version 4 (à moins que ce soit 5 ), et la nouveautés de la future version Firebird 6 mettrons peut-être à mal tes critiques mais je ne suis pas assez calé pour en débattre

[SQLpro]

Beaucoup de choses changent, le chiffrement existe de façon plus simple depuis la version 4 (à moins que ce soit 5 ), ...

Oui, mais toujours pas de TDE qui chiffre l'intégralité de la base sans affecter les performances des requêtes....

A +

[bash.net]

Bonjour,

Merci pour ces échanges.
Je n'ai pas grand chose à rajouter sinon que toutes mes tables sont bien indexées et que j'utilise un SGBD afin d'effectuer des requêtes SQL sur les données (pour celui qui a posé la question).
Qu'est-ce que vous voulez, j'ai toujours été déçu par la performance des SGBD, mais c'est peut-être parce que je n'utilise pas les meilleurs et/ou que je ne sais pas comment m'y prendre avec ces bêtes là.

Mais justement, au sujet du chiffrement non pris en charge par certain SGBD.
Le chiffrement du média (volume, partition, dossier) où se trouve le fichier de données n'est-il pas la solution alternative ?

Encore merci.

[Michel.Priori]

Le chiffrement du média (volume, partition, dossier) où se trouve le fichier de données n'est-il pas la solution alternative ?

Que très partiellement.
1. le backup n'est pas crypté
2. l'accès aux données par les DBA et les admin du serveur reste possible

Par exemple : si on est sous Windows et qu'on utilise EFS
Le cryptage/décryptage n'est pas visible du SGBD => pas d'audit, pas moyen de valider sa mise en oeuvre
L'ouverture des fichiers, en clair, n'est possible que pour les comptes qui ont accès aux clés => le SGBD, ce à quoi faut ajouter les binaires qui font la sauvegarde (c'est le cas quand le backup n'est pas un ordre SQL) ; mais les copies sont faites en clair (sauf si on passe par une copie Windows ET que la destination est un volume NTFS)

Plus généralement, ajouter une couche externe pour accéder aux disques = problèmes de perf

En clair : ce n'est pas une alternative.

[SQLpro]

... Le problème de performance d'une base de données provient généralement des filtres qui prennent du temps à s’exécuter. Le temps CPU pour exécuter un filtre SQL est équivalent à un filtre qu'on ferait avec une boucle FOR pour tester si chaque champs doit être filtré ou non. Donc si il y a beaucoup d'enregistrements le filtre prendra forcément plus de temps.

Visiblement vous avez raté les cours sur les SGBDR...

1) la notion d'enregistrement n'existe pas dans les SGDR.
https://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2
Il y a des lignes au niveau logique et des pages au niveau physique. Les performances sont liées au nombre de pages lues et non pas au nombre de lignes lues...

2) connaissez vous les index ? Visiblement non.... Les index sont fait pour faire passer un temps linéaire en temps logarithmique (voire beaucoup plus). Lisez par exemple l'étude que j'ai donné en 2007 à ce sujet...
https://sqlpro.developpez.com/optimisation/indexation/
Vous verrez que dans une table de plus d'un million de ligne, un index bien choisi divise le temps d'accès par un facteur 420... Les technologies évoluant aujourd'hui ce facteur est supérieur à 1000 avec des index filtrés ou compressé et près de 1 millions de fois plus rapide avec l'indexation verticale (columnstore par exemple dans SQL Server)
En complément, lecture indispensable :
https://blog.developpez.com/sqlpro/p...ut_sur_l_index

...Notre structure de la base de données a été pensée pour que les recherches SQL soient instantanées, qu'elles soient exécutées en intranet, en extranet ou depuis internet. En limitant les filtres on gagne énormément en performance, mais c'est au prix d'un nombre de tables importants. Il y a toujours une contrainte quelque part quand on cherche à optimiser.

Cela était vrai du temps du Cobol dans les années 60... On est en 2025 des bases de données de plus de 10 To sont légion (CDiscount, Fnac.com, Veepee.... ) utilisent du SQL Server avec des bases monolithique (tout est dans une seule et même base) allant de 25 à 50 To contenant des tables qui ont en moyenne plusieurs dizaines de millions de lignes.... et pour certaines quelques milliards ! Je ne sais pas si vous êtes allés sur ces sites mais les réponses sont instantanées !
Votre cerveau semble s'être figé aux années 70 !

Il n'y a pas de duplication ou de redondance de données dans notre structure, juste un découpage des données très optimisé.

ben non, c'est pas optimisé du tout. Et pour la maintenance et l'évolution de votre modèle de données c'est catastrophique !

A +

[SQLpro]

...
Mais justement, au sujet du chiffrement non pris en charge par certain SGBD.
Le chiffrement du média (volume, partition, dossier) où se trouve le fichier de données n'est-il pas la solution alternative ?

Le chiffrement ne peut être qu'interne.... Sinon comment voulez vous accéder aux données ? Il faudrait déchiffrer l'intégralité du stockage à chaque accès pour retrouver Paul Durand.
la plupart des SGBDR possèdent des routines de chiffrement interne. Pour les SGBDR libre, c'est généralement mal fait :
1) clé de déchiffrement devant être présente en clair quelque part (sur le serveur), alors que certains SGBDR permettent un contrôle de sécurité interne des clés qui ne sont jamais exposées
2) pas de salage automatique, indispensable pour le chiffrement des collections
3) rarement du chiffrement de bout en bout
Pour les grand SGBDR il existe le chiffrement du stockage, appelé TDE pour Transparent Data Encryption. Cela présente l'avantage de chiffrer intégralement la base et ne pèse que très peu sur les performances...

A +

[SQLpro]

... Qu'est-ce que vous voulez, j'ai toujours été déçu par la performance des SGBD, mais c'est peut-être parce que je n'utilise pas les meilleurs et/ou que je ne sais pas comment m'y prendre avec ces bêtes là.

Il y a aussi quelques conditions à remplir pour qu'un SGBDR soit efficace au niveau du système....
1) les données étant traitées exclusivement en RAM, il en faut beaucoup. Personnellement j'exige au moins 24 Go de RAM et beaucoup plus suivant la taille de la base et le nombre d'utilisateur
2) si vous utilisez une VM il faut régler la VM pour que les ressources soient fixes
3) il faut prioriser les services (ou daemon) au niveau de l'OS et non les applications
4) il faut effectuer une maintenance régulière des espaces de stockage (défragmentation, réindexation, recalcul des statistiques de l'optimiseur...)
5) il faut analyser les requêtes effectuées, détecter celles qui sont contre-performantes et les indexer. Certains SGBDR comme SQL Server diagnostiquent tout cela automatiquement
6) il ne faut installer aucune application ou service/daemon sur la machine exécutant le SGBDR
...

A +

[Artemus24]

Salut à tous.

Juste par curiosité, combien y-a-t-il de lignes, en moyenne, dans vos tables ?