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 ;-)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Roi Dieu PurR=c3=aa M=c3=a9ta-Maitre en M=c3=a9ta-Science
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: <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 ;-)
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...
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:
<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 ;-)
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...
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: <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 ;-)
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...
