MacCafé et compression base de données

Le
Gilbert OLIVIER Avatar par défaut
Bonjour

J'ouvre un nouveau fil (l'autre partant dans tous les sens) pour
donner quelques informations au sujet de ce que je pense de la
compression. C'est ce que je pense et je peux avoir totalement tord…

Globalement, il est inutile de courir après une "occupation globale"
(pour reprendre le terme de 4D) proche de 100%.

Dans certains cas, il me semble peut être intéressant d'y recourir.
Par exemple, vous avez une assez grosse base (à la louche au moins
100 à 200 mille messages) dont vous allez purger beaucoup de messages
(toujours à la louche au moins 1/3), avec dans l'idée à partir de ce
moment de purger plus régulièrement, de façon à ne plus atteindre ce
nombre.

Pour une utilisation avec une purge régulière qui supprimera
sensiblement à chaque fois le même nombre de messages, c'est à mon
avis totalement inutile à chaque purge.

Maintenant, ce terme de "global" n'est pas là par hasard.
Sauf erreur on peut par analogie comparer l'organisation du fichier
de données à un filesytem ou chaque table serait un fichier.
Et c'est peut-être pour ça que 4D préconise de compacter à partir
d'un certains pourcentage global, dans l'idée que si ce pourcentage
est arrivé à cette valeur c'est qu'il y a de fortes chances que la
fragmentation des données d'une même table n'est plus négligeable. Le
compactage de la totalité de la base réglant ce problème.

Maintenant, c'est vrai que j'ai déjà constaté une amélioration
visible des performances après un compactage, mais c'était en période
de développement touchant profondément à la structure de la base.
En usage normal, je n'ai aucune idée de la périodicité à laquelle le
conseiller pour cette raison.
Si vous constatez une augmentation qui vous semble sensible ET
constante du temps d'affichage des messages à la lecture peut-être
est-ce le bon moment.
Le type de disque devant aussi je pense influencer la perception de
cette diminution de réactivité (qui sera moins évidente sur un SSD,
l'accès disque pour charger les "morceau" de données en cache étant
plus rapide).

Dans tous les cas je ne peux que vous conseiller d'être prudent en
utilisant le CSM.

Pour plus de détails sur ses commandes, reportez-vous à la doc de 4D
ici:
<https://doc.4d.com/4Dv17/4D/17.4/Centre-de-Securite-et-de-Maintenance.200-4880469.fr.html>
ou en cliquant sur le boutons "Documentation en ligne" au dessus du
bouton "CSM".

Un dernier mots sur les fichiers de la base donnée, ce sont les
fichiers par excellence à exclure de la sauvegarde de TimeMachine.
Les modifications y étant pratiquement constante à l'utilisation du
programme, je pense surtout s'ils sont un peu gros, qu'ils doivent
saturer rapidement l'espace disque de sauvegarde ;-)

--
Gilbert
<https://maccafe-osx.pagesperso-orange.fr>
Vos réponses
Trier par : date / pertinence
Roi Dieu PurR=c3=aa M=c3=a9ta-Maitre en M=c3=a9ta-Science Avatar par défaut
Le #26547799
Le 31/05/2020 à 19:15:59, Gilbert OLIVIER a écrit :
Bonjour
J'ouvre un nouveau fil (l'autre partant dans tous les sens) pour
donner quelques informations au sujet de ce que je pense de la
compression. C'est ce que je pense et je peux avoir totalement tord…
Globalement, il est inutile de courir après une "occupation globale"
(pour reprendre le terme de 4D) proche de 100%.
Dans certains cas, il me semble peut être intéressant d'y recourir.
Par exemple, vous avez une assez grosse base (à la louche au moins
100 à 200 mille messages) dont vous allez purger beaucoup de messages
(toujours à la louche au moins 1/3), avec dans l'idée à partir de ce
moment de purger plus régulièrement, de façon à ne plus atteindre ce
nombre.
Pour une utilisation avec une purge régulière qui supprimera
sensiblement à chaque fois le même nombre de messages, c'est à mon
avis totalement inutile à chaque purge.
Maintenant, ce terme de "global" n'est pas là par hasard.
Sauf erreur on peut par analogie comparer l'organisation du fichier
de données à un filesytem ou chaque table serait un fichier.
Et c'est peut-être pour ça que 4D préconise de compacter à partir
d'un certains pourcentage global, dans l'idée que si ce pourcentage
est arrivé à cette valeur c'est qu'il y a de fortes chances que la
fragmentation des données d'une même table n'est plus négligeable. Le
compactage de la totalité de la base réglant ce problème.
Maintenant, c'est vrai que j'ai déjà constaté une amélioration
visible des performances après un compactage, mais c'était en période
de développement touchant profondément à la structure de la base.
En usage normal, je n'ai aucune idée de la périodicité à laquelle le
conseiller pour cette raison.
Si vous constatez une augmentation qui vous semble sensible ET
constante du temps d'affichage des messages à la lecture peut-être
est-ce le bon moment.
Le type de disque devant aussi je pense influencer la perception de
cette diminution de réactivité (qui sera moins évidente sur un SSD,
l'accès disque pour charger les "morceau" de données en cache étant
plus rapide).
Dans tous les cas je ne peux que vous conseiller d'être prudent en
utilisant le CSM.
Pour plus de détails sur ses commandes, reportez-vous à la doc de 4D
ici:
ou en cliquant sur le boutons "Documentation en ligne" au dessus du
bouton "CSM".
Un dernier mots sur les fichiers de la base donnée, ce sont les
fichiers par excellence à exclure de la sauvegarde de TimeMachine.
Les modifications y étant pratiquement constante à l'utilisation du
programme, je pense surtout s'ils sont un peu gros, qu'ils doivent
saturer rapidement l'espace disque de sauvegarde ;-)


déjà dé la premier version MacCafé est une usine à gaz... la faute a qui
la faut à 4D...
J’aimerai connaitre ton impression sur l'avenir de MacCafé ?
--
/ Croire c'est le contraire de savoir,
-- o -- si j'y crois, je ne sais pas,
/ si je sais, pas la peine d'y croire.
--> Je Croix Pas, car Je Sais que c'est Faux MalgRê TouT...
Publicité
Poster une réponse
Anonyme Avatar par défaut