Discussion :

[sevyc64]

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.

[SergioMaster]

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 .

[sevyc64]

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?

[SergioMaster]

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

[sevyc64]

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.

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.

[SergioMaster]

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 ?

[SergioMaster]

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

[makowski]

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.

[vanquish]

Bonjour,

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

[sevyc64]

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

[SergioMaster]

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

[sevyc64]

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