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

Firebird Discussion :

Choix entre un varchar ou un blob


Sujet :

Firebird

  1. #1
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 962
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 962
    Points : 27 031
    Points
    27 031
    Par défaut Choix entre un varchar ou un blob
    Salut les adeptes de l'oiseau de feu

    Je dois modifier un champ dans une base Firebird 2.5 car il est trop petit (saisie libre d'un commentaire par l'utilisateur). Actuellement c'est un varchar(255).

    Quel serait le meilleur choix en terme de taille et de performance, soit un varchar(x) avec x probablement supérieur à 2000, ou carrément un blob ?

    Perso, je serais plutôt partant pour un varchar, les décideurs parlent de blob pour ne pas être "emmerdé".
    Pour le varchar, la modif est à priori immédiate, pour le blob, il va falloir, je pense, passer par de la récupération des données existantes, et peut-être de la modification de code, je présume.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  2. #2
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 380
    Points : 36 260
    Points
    36 260
    Billets dans le blog
    54
    Par défaut
    Bonjour,

    un varchar peut faire jusqu'à 32767 octets (en fonction de l'encodage la taille en caractères peut donc être moins importante 8000 en UTF32, sans espace et qu'avec des caractères très 'exotiques' ) , un blob doit "juste" être inférieur à 32Go.

    cela étant tout dépend de ce que tu vas en faire de ce champ ? J'imagine bien qu'il ne s'agira pas d'un index quelconque.

    pour le blob, il va falloir, je pense, passer par de la récupération des données existantes, et peut-être de la modification de code, je présume.
    'don't ASS/U/ME' me disait un chef de projet anglais un peu grivois sur les bords
    OUI , il faudra certainement une modification de code , quoique cela dépende du langage , du mode d'accès etc... i.e. avec delphi , pour un blob text , pas besoin il suffit de traiter le blob comme un ... Varchar mais bien sur la taille doit être inférieure à 32Ko
    pour la mise à jour des données oui il faudra passer par une récupération , mais c'est rapide : créer le blob , faire un UPDATE BLOB=CHAMP , puis supprimer le champ.

    Perso je pencherai pour le VARCHAR .
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  3. #3
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 962
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 962
    Points : 27 031
    Points
    27 031
    Par défaut
    le champ contient un commentaire facultatif saisi par l'utilisateur, donc uniquement du texte avec possiblement quelques caractères exotiques, accent, ponctuation, ...
    Même à 8000 caractères en UTF32, ça devrait être suffisant. A l'heure actuelle le champ est limité à 255 caractères depuis plusieurs années et on a pas eu énormément de remonté comme quoi il est trop petit.

    Le code est bien en Delphi, pour les modifications, donc, que ce soit blob ou varchar, il n'y en aura donc pas à priori, si ce n'est peut-être des maxlenght sur les champs de saisie, mais ce n'est pas le sujet.

    Niveau base, le ALTER TABLE ne suffira pas avec le blob, mais la manip n'est pas rédhibitoire non plus, d'autant plus qu'elle sera faite en automatique par un patch de mise à jour.

    Par contre, mon interrogation porte plus sur le stockage réel sur le disque. A priori le varchar n'utilisent que les octets réellement nécessaire pour stocker le texte. Quand est-il du blob, fait-il pareil ou réserve-t-il des blocs de taille fixe indépendamment de la taille réelle à stocker ?

    Et niveau performance en lecture/écriture/mise à jour d'une ligne sur une table, par exemple, pouvant contenir plusieurs milliers de lignes, faut-il s'attendre à des différences notables?
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  4. #4
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 380
    Points : 36 260
    Points
    36 260
    Billets dans le blog
    54
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    le champ contient un commentaire facultatif saisi par l'utilisateur, donc uniquement du texte avec possiblement quelques caractères exotiques, accent, ponctuation, ...
    Même à 8000 caractères en UTF32, ça devrait être suffisant.
    Quand je disais 8000 caractères en UTF32 c'était s'il n'y avait aucune possibilité compression des caractères bien sur, ce qui n'est pas le cas de UTF32, donc ce n'est pas quelques accents qui vont gêner je donnais cette barre de 8000 en supposant que ce ne soit que des caractères "exotiques" nécessitant les 4octets pour être encodés (même en chinois je pense que cela passerait largement la barre des 16000 !)
    Par contre, mon interrogation porte plus sur le stockage réel sur le disque. A priori le varchar n'utilisent que les octets réellement nécessaire pour stocker le texte. Quand est-il du blob, fait-il pareil ou réserve-t-il des blocs de taille fixe indépendamment de la taille réelle à stocker ?
    alors là, on creuse en profondeur, la mode n'est plus vraiment à faire attention au coût octal de stockage comme au siècle dernier dans les décennies<90 (dommage). Pour ce que j'en sais et peut être me trompe-je :
    - Un Varchar ajoute quelques octets* pour stocker la taille de la chaîne
    - un Blob c'est quelques octets* dans la table contenant une adresse pointant sur le contenu
    (*4 ou 8 je doute)
    donc , à mon humble avis le coût est le même

    Et niveau performance en lecture/écriture/mise à jour d'une ligne sur une table, par exemple, pouvant contenir plusieurs milliers de lignes, faut-il s'attendre à des différences notables?
    niveau performances je dirais (toujours AMHA) que VARCHAR sera plus rapide
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  5. #5
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 962
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 962
    Points : 27 031
    Points
    27 031
    Par défaut
    Citation Envoyé par SergioMaster Voir le message
    alors là, on creuse en profondeur, la mode n'est plus vraiment à faire attention au coût octal de stockage comme au siècle dernier dans les décennies<90 (dommage).
    Il est vrai, mais avec les bases que l'on manipule ici, j'ai l'impression que Firebird ne devient plus trop performant dès lors le fichier fdb s'approche ou dépasse le Go.
    Moi qui suis habitué à SQL Server avec des bases dépassant facilement les 1000Go (taille du backup), avec l'expérience que j'ai de Firebird depuis 1 an, je ne tenterais même pas.

    Citation Envoyé par SergioMaster Voir le message
    Pour ce que j'en sais et peut être me trompe-je :
    - Un Varchar ajoute quelques octets* pour stocker la taille de la chaîne
    - un Blob c'est quelques octets* dans la table contenant une adresse pointant sur le contenu
    (*4 ou 8 je doute)
    donc , à mon humble avis le coût est le même

    niveau performances je dirais (toujours AMHA) que VARCHAR sera plus rapide
    Donc j'en conclue que, globalement, rien ne plaide en faveur ni en défaveur, ni de l'un, ni de l'autre. Ça sera donc à la préférence de celui qui décidera. Je vais donc milité pour le varchar.

    Merci pour tes réponses.
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  6. #6
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 380
    Points : 36 260
    Points
    36 260
    Billets dans le blog
    54
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Il est vrai, mais avec les bases que l'on manipule ici, j'ai l'impression que Firebird ne devient plus trop performant dès lors le fichier fdb s'approche ou dépasse le Go.
    Je suis loin d'atteindre de telles tailles et serait donc bien en peine d'en parler peut-être que si makowski passe par ici pourra t-il nous répondre plus précisément ?
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  7. #7
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 380
    Points : 36 260
    Points
    36 260
    Billets dans le blog
    54
    Par défaut
    Bonjour,

    un petit nota bene qui pourrait donner un peu plus de poids aux Varchar , il semblerait que l'accès aux blobs via Firedac pénalise la vitesse (1.5 à 2 fois plus de temps nécessaire) et la mémoire (4 * la taille du mémo).
    Bon je n'ai pas tout compris aux explications de Dmitry Arefiev la qualité du son (ou son phrasé) n'est pas très clair
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  8. #8
    Membre expert

    Homme Profil pro
    Consultant spécialité Firebird
    Inscrit en
    mai 2002
    Messages
    2 342
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France

    Informations professionnelles :
    Activité : Consultant spécialité Firebird
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 2 342
    Points : 3 701
    Points
    3 701
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Il est vrai, mais avec les bases que l'on manipule ici, j'ai l'impression que Firebird ne devient plus trop performant dès lors le fichier fdb s'approche ou dépasse le Go.
    Tous les clients d'IBPhoenix que je connais ont des bases qui font des centaines de Go sans aucun problème.
    Philippe Makowski
    IBPhoenix - Firebird
    Membre de l'April

  9. #9
    Membre expérimenté

    Profil pro
    Chef de Projet / Développeur
    Inscrit en
    juin 2002
    Messages
    517
    Détails du profil
    Informations personnelles :
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Chef de Projet / Développeur
    Secteur : Santé

    Informations forums :
    Inscription : juin 2002
    Messages : 517
    Points : 1 547
    Points
    1 547
    Par défaut
    Bonjour,

    Citation Envoyé par sevyc64 Voir le message
    Il est vrai, mais avec les bases que l'on manipule ici, j'ai l'impression que Firebird ne devient plus trop performant dès lors le fichier fdb s'approche ou dépasse le Go.
    Je travaille sur une base qui fait 20 Go, 4 tables dont une fait 85 millions d'enregistrements.
    L'accès reste très convenable tant qu'il se fait sur des champs indexés.

    Par contre les INSERT deviennent assez lent quand les indexes sont actifs (plusieurs centaines à la seconde quand même / mais comparé aux perfs initiales, il y a un vrai ralentissement de ce coté).

    C'est mono-utilisateur (comme souvent le cas sur un site web).
    --
    vanquish

  10. #10
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 962
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 962
    Points : 27 031
    Points
    27 031
    Par défaut
    C'est un peu le problème de mes bases (enfin celles que je manipule, parce que si ça tenait qu'à moi ...). Plus de la moitié des tables sans clé primaire déclarée (quelques une même sans champ pouvant faire office de clé), aucune clé étrangère déclarée. Donc évidemment aucun contrôle d'intégrité. Données redondantes, données scindées sur 2 ou 3 tables, ou au contraire tables avec plusieurs fonctions,... Il y a quand même quelques index, mais sont-ils pertinent ?
    J'ai même une des tables principales qui a un champ qui devrait être une clé étrangère sur elle-même, mais qui a, en réalité, 2 fonctions suivant le type d'enregistrement (la clé primaire n'étant évidemment pas déclaré comme telle sur cette table). Je ne peux donc même pas rajouter cette satané contrainte pour résoudre quelques problèmes

    Et évidemment, aucun schéma, diagramme, ni même étude, cahier des charges, docs, ....
    Brefs il y a même des tables dont personne n'est capable de dire à quoi elles servent, personne ne peut dire s'il faut absolument les conserver ou si on peut s'en séparer.

    Bien entendu, le logiciel exploitant cela, développé en Delphi 6, est à l'image de la base
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  11. #11
    Rédacteur/Modérateur

    Avatar de SergioMaster
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    13 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 65
    Localisation : France, Loire Atlantique (Pays de la Loire)

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

    Informations forums :
    Inscription : janvier 2007
    Messages : 13 380
    Points : 36 260
    Points
    36 260
    Billets dans le blog
    54
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    C'est un peu le problème de mes bases (enfin celles que je manipule, parce que si ça tenait qu'à moi ...). Plus de la moitié des tables sans clé primaire déclarée (quelques une même sans champ pouvant faire office de clé), aucune clé étrangère déclarée.
    si tu peux modifier la structure de la base de données, rien de t'empêcherais d'avoir un champ autoincrémenté (ENUMERATOR) par table servant de clé primaire et un TRIGGER BEFORE INSERT pour le remplir, cela n'implique qu'un peu d'huile de coude (la création de l'enumérateur du champ, du trigger et une "première fois" : EXECUTE BLOCK pour remplir le champ pour les enregistrements existants avant de créer la primary key


    Et évidemment, aucun schéma, diagramme, ni même étude, cahier des charges, docs, ....
    Brefs il y a même des tables dont personne n'est capable de dire à quoi elles servent, personne ne peut dire s'il faut absolument les conserver ou si on peut s'en séparer.
    Bien entendu, le logiciel exploitant cela, développé en Delphi 6, est à l'image de la base
    Les "joies" d'un reprise en maintenance
    Delphi installés : D3,D7,D2010,XE4,XE7,D10 (Tokyo, Rio, Sidney) ,D11 (Alexandria)
    SGBD : Firebird 2.5, 3, SQLite
    générateurs Etats : FastReport, Rave, QuickReport
    OS : Window Vista, Windows 10, Ubuntu, Androïd

  12. #12
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    janvier 2007
    Messages
    9 962
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : janvier 2007
    Messages : 9 962
    Points : 27 031
    Points
    27 031
    Par défaut
    Citation Envoyé par SergioMaster Voir le message
    si tu peux modifier la structure de la base de données, rien de t'empêcherais d'avoir un champ autoincrémenté (ENUMERATOR) par table servant de clé primaire et un TRIGGER BEFORE INSERT pour le remplir, cela n'implique qu'un peu d'huile de coude (la création de l'enumérateur du champ, du trigger et une "première fois" : EXECUTE BLOCK pour remplir le champ pour les enregistrements existants avant de créer la primary key
    Oui, d'autant plus que beaucoup de tables ont déjà ce champs géré comme clé primaire mais par le code.
    Mais la modification de la base n'est pas d'actualité. Au delà de tous les tests de validation qu'il faudrait refaire il faudrait manuellement corriger les bases de nos près de 1000 clients avant
    avant de pouvoir modifier leur base. Et ça c'est pas envisageable pour la hotline
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Choix entre deux champs dans une requete
    Par Pico10 dans le forum SQL Procédural
    Réponses: 3
    Dernier message: 27/07/2005, 16h36
  2. a href : choix entre OUVRIR ou TELECHARGER
    Par lepierre dans le forum Balisage (X)HTML et validation W3C
    Réponses: 5
    Dernier message: 21/06/2005, 15h51
  3. choix entre dbexpress et objet interbase
    Par hani dans le forum Bases de données
    Réponses: 5
    Dernier message: 19/11/2004, 00h09
  4. Conseille Choix entre MySQL et InterBase?
    Par Redhouane dans le forum Bases de données
    Réponses: 3
    Dernier message: 28/09/2004, 12h42
  5. choix entre macro et fonction
    Par remi77 dans le forum C
    Réponses: 4
    Dernier message: 22/10/2003, 15h26

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