IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Firebird Discussion :

Nombre de tables maximum atteint


Sujet :

Administration Firebird

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Invité de passage
    Profil pro
    Inscrit en
    Février 2011
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 4
    Par défaut 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.

  2. #2
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 69
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 660
    Billets dans le blog
    65
    Par défaut
    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
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  3. #3
    Invité de passage
    Profil pro
    Inscrit en
    Février 2011
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 4
    Par défaut
    Citation Envoyé par SergioMaster Voir le message
    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 ?

  4. #4
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 69
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 660
    Billets dans le blog
    65
    Par défaut
    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.
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 637
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 637
    Billets dans le blog
    10
    Par défaut
    Bonjour,


    Citation Envoyé par bash.net Voir le message
    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 Voir le message
    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 !

  6. #6
    Invité de passage
    Profil pro
    Inscrit en
    Février 2011
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 4
    Par défaut
    Citation Envoyé par escartefigue Voir le message

    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.

  7. #7
    Membre Expert
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 963
    Par défaut
    Citation Envoyé par bash.net Voir le message
    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 ?
    Le savoir est une nourriture qui exige des efforts.

  8. #8
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 637
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 637
    Billets dans le blog
    10
    Par défaut
    Citation Envoyé par bash.net Voir le message
    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.

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par bash.net Voir le message
    ... 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


    Citation Envoyé par bash.net Voir le message
    ...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 !

    Citation Envoyé par bash.net Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par bash.net Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  11. #11
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique retraité
    Inscrit en
    Janvier 2007
    Messages
    15 660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 69
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Janvier 2007
    Messages : 15 660
    Billets dans le blog
    65
    Par défaut
    Je me doutais que tu passerais par là. étonnant que tu n'aies pas relevé la partie MySQL

    Citation Envoyé par SQLpro Voir le message
    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
    MVP Embarcadero
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Rio, Sidney), D11 (Alexandria), D12 (Athènes)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs États : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Windows 11, Ubuntu, Androïd

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par SergioMaster Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  13. #13
    Invité de passage
    Profil pro
    Inscrit en
    Février 2011
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2011
    Messages : 4
    Par défaut 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.

  14. #14
    Membre Expert
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Septembre 2016
    Messages
    963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2016
    Messages : 963
    Par défaut
    Citation Envoyé par bash.net Voir le message
    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.
    Le savoir est une nourriture qui exige des efforts.

  15. #15
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par bash.net Voir le message
    ...
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  16. #16
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    22 010
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 22 010
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par bash.net Voir le message
    ... 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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Nombre d'enregistrements maximum dans une table sql server
    Par maxime_01 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 10/05/2009, 16h49
  2. Nombre de colonnes maximum d'une table mysql
    Par tulipeverte dans le forum SQL Procédural
    Réponses: 4
    Dernier message: 08/02/2008, 15h54
  3. Nombre de tables maximum
    Par Invité dans le forum SQL Procédural
    Réponses: 9
    Dernier message: 20/01/2008, 22h17
  4. Réponses: 4
    Dernier message: 10/05/2007, 07h30
  5. Réponses: 5
    Dernier message: 25/11/2003, 09h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo