Nombre de tables maximum atteint

Version imprimable

18/08/2025, 07h37
bash.net

Nombre de tables maximum atteint

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.

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.

Citation:

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

Citation:

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

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

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

18/08/2025, 17h04
escartefigue

Bonjour,

Citation:

Envoyé par bash.net

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

Citation:

Envoyé par bash.net

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 !
19/08/2025, 10h54
bash.net

Citation:

Envoyé par escartefigue

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.

Citation:
Envoyé par 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.

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:

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 ?

20/08/2025, 09h21
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.
21/08/2025, 09h20
Michel.Priori

Citation:

Envoyé par bash.net

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 ?
21/08/2025, 13h53
escartefigue

Citation:

Envoyé par bash.net

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.
22/08/2025, 17h08
SQLpro
Citation:

Envoyé par bash.net

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 +
23/08/2025, 08h36
SergioMaster

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

Citation:

Envoyé par SQLpro

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 :koi:), 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
27/08/2025, 13h06
SQLpro

Citation:

Envoyé par SergioMaster

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

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

A +
06/09/2025, 16h43
bash.net

Chiffrement

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.
07/09/2025, 19h50
Michel.Priori

Citation:

Envoyé par bash.net

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.