J'ai une base hyperfile et je me suis rendu compte que la taille de mes
fichiers FIC avaient une proportion étonnante ...
du style : 600 enregistrements avec une table contenant 15 champs et
bien ca me fait un fichier de plus de 1 Mo !! bisarre non ?
Ca va donner quoi qd je vais mettre 60000 entrées ?
J'ai importé mes données depuis une base Mysql ... et la taille des tables (HF vs MySQL) sont carréments différentes ... par exemple sur ma table absences, tout confondu en mysql ca pese : 877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282 octets !! c'est mal optimisé dans les fichiers ou quoi ?
La taille du fichier d'index depend du nombre et de la taille des champs indexés. Une bonne analyse commence toujours par la description des fichiers.
Poses-toi les bonnes questions et tu trouveras certainement les réponses. As-tu besoin de tant d'index ? Nom et prénom ne sont-ils pas suffisants ? D'autre part, connais-tu beaucoup de Nom ou prénom de 80 caractères ? Des adresses de 255 caractères ? Des numéros de téléphone de 20 caractères ?
Ta solution réside simplement dans l'optimisation des champs de fichier.
--- Eric LAURENT
Olivier BONNAURE <soli@netcourrier.com> a écrit:
J'ai importé mes données depuis une base Mysql ... et la taille des
tables (HF vs MySQL) sont carréments différentes ...
par exemple sur ma table absences, tout confondu en mysql ca pese :
877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282
octets !! c'est mal optimisé dans les fichiers ou quoi ?
La taille du fichier d'index depend du nombre et de la taille des champs
indexés.
Une bonne analyse commence toujours par la description des fichiers.
Poses-toi les bonnes questions et tu trouveras certainement les réponses.
As-tu besoin de tant d'index ? Nom et prénom ne sont-ils pas suffisants ?
D'autre part, connais-tu beaucoup de Nom ou prénom de 80 caractères ?
Des adresses de 255 caractères ?
Des numéros de téléphone de 20 caractères ?
Ta solution réside simplement dans l'optimisation des champs de fichier.
J'ai importé mes données depuis une base Mysql ... et la taille des tables (HF vs MySQL) sont carréments différentes ... par exemple sur ma table absences, tout confondu en mysql ca pese : 877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282 octets !! c'est mal optimisé dans les fichiers ou quoi ?
La taille du fichier d'index depend du nombre et de la taille des champs indexés. Une bonne analyse commence toujours par la description des fichiers.
Poses-toi les bonnes questions et tu trouveras certainement les réponses. As-tu besoin de tant d'index ? Nom et prénom ne sont-ils pas suffisants ? D'autre part, connais-tu beaucoup de Nom ou prénom de 80 caractères ? Des adresses de 255 caractères ? Des numéros de téléphone de 20 caractères ?
Ta solution réside simplement dans l'optimisation des champs de fichier.
--- Eric LAURENT
Romain PETIT
Olivier BONNAURE a écrit :
J'ai importé mes données depuis une base Mysql ... et la taille des tables (HF vs MySQL) sont carréments différentes ... par exemple sur ma table absences, tout confondu en mysql ca pese : 877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282 octets !! c'est mal optimisé dans les fichiers ou quoi ?
- Quelle version de WD/HF (il me semble qu'un problème de taille de fichiers NDX avec une vieille version de WD7.5 avait été corrigé) ? - si HF7, est-ce une migration WD55 avec conservation du mode compatible 55 (rubriques textes complètées par des espaces ) ? - ya-t-il ou pas compression des mémos éventuels ? - les fichiers NDX sont d'autant plus importants que le nombre de tes clés de ton fichier l'est aussi... Tes rubriques sont-elles toutes des clés ?
A+ (au fait, pourquoi vouloir migrer du MySQL vers HF ?)
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Olivier BONNAURE a écrit :
J'ai importé mes données depuis une base Mysql ... et la taille des tables
(HF vs MySQL) sont carréments différentes ...
par exemple sur ma table absences, tout confondu en mysql ca pese : 877,8 kb,
en HF : le FIC pèse : 657307 octets et le NDX : 1907282 octets !!
c'est mal optimisé dans les fichiers ou quoi ?
- Quelle version de WD/HF (il me semble qu'un problème de taille de
fichiers NDX avec une vieille version de WD7.5 avait été corrigé) ?
- si HF7, est-ce une migration WD55 avec conservation du mode
compatible 55 (rubriques textes complètées par des espaces ) ?
- ya-t-il ou pas compression des mémos éventuels ?
- les fichiers NDX sont d'autant plus importants que le nombre de tes
clés de ton fichier l'est aussi... Tes rubriques sont-elles toutes des
clés ?
A+
(au fait, pourquoi vouloir migrer du MySQL vers HF ?)
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
J'ai importé mes données depuis une base Mysql ... et la taille des tables (HF vs MySQL) sont carréments différentes ... par exemple sur ma table absences, tout confondu en mysql ca pese : 877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282 octets !! c'est mal optimisé dans les fichiers ou quoi ?
- Quelle version de WD/HF (il me semble qu'un problème de taille de fichiers NDX avec une vieille version de WD7.5 avait été corrigé) ? - si HF7, est-ce une migration WD55 avec conservation du mode compatible 55 (rubriques textes complètées par des espaces ) ? - ya-t-il ou pas compression des mémos éventuels ? - les fichiers NDX sont d'autant plus importants que le nombre de tes clés de ton fichier l'est aussi... Tes rubriques sont-elles toutes des clés ?
A+ (au fait, pourquoi vouloir migrer du MySQL vers HF ?)
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Olivier BONNAURE
Romain PETIT a écrit :
Olivier BONNAURE a écrit :
J'ai importé mes données depuis une base Mysql ... et la taille des tables (HF vs MySQL) sont carréments différentes ... par exemple sur ma table absences, tout confondu en mysql ca pese : 877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282 octets !! c'est mal optimisé dans les fichiers ou quoi ?
- Quelle version de WD/HF (il me semble qu'un problème de taille de fichiers NDX avec une vieille version de WD7.5 avait été corrigé) ? - si HF7, est-ce une migration WD55 avec conservation du mode compatible 55 (rubriques textes complètées par des espaces ) ? - ya-t-il ou pas compression des mémos éventuels ? - les fichiers NDX sont d'autant plus importants que le nombre de tes clés de ton fichier l'est aussi... Tes rubriques sont-elles toutes des clés ?
A+ (au fait, pourquoi vouloir migrer du MySQL vers HF ?)
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Romain PETIT a écrit :
Olivier BONNAURE a écrit :
J'ai importé mes données depuis une base Mysql ... et la taille des
tables (HF vs MySQL) sont carréments différentes ...
par exemple sur ma table absences, tout confondu en mysql ca pese :
877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282
octets !!
c'est mal optimisé dans les fichiers ou quoi ?
- Quelle version de WD/HF (il me semble qu'un problème de taille de
fichiers NDX avec une vieille version de WD7.5 avait été corrigé) ?
- si HF7, est-ce une migration WD55 avec conservation du mode compatible
55 (rubriques textes complètées par des espaces ) ?
- ya-t-il ou pas compression des mémos éventuels ?
- les fichiers NDX sont d'autant plus importants que le nombre de tes
clés de ton fichier l'est aussi... Tes rubriques sont-elles toutes des
clés ?
A+
(au fait, pourquoi vouloir migrer du MySQL vers HF ?)
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer
(par cd ou en ligne) donc je vois mal les utilisateurs devoir installer
MySql ... et aussi pour le pb des licences
J'ai importé mes données depuis une base Mysql ... et la taille des tables (HF vs MySQL) sont carréments différentes ... par exemple sur ma table absences, tout confondu en mysql ca pese : 877,8 kb, en HF : le FIC pèse : 657307 octets et le NDX : 1907282 octets !! c'est mal optimisé dans les fichiers ou quoi ?
- Quelle version de WD/HF (il me semble qu'un problème de taille de fichiers NDX avec une vieille version de WD7.5 avait été corrigé) ? - si HF7, est-ce une migration WD55 avec conservation du mode compatible 55 (rubriques textes complètées par des espaces ) ? - ya-t-il ou pas compression des mémos éventuels ? - les fichiers NDX sont d'autant plus importants que le nombre de tes clés de ton fichier l'est aussi... Tes rubriques sont-elles toutes des clés ?
A+ (au fait, pourquoi vouloir migrer du MySQL vers HF ?)
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Romain PETIT
Olivier BONNAURE a écrit :
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/ - Open source et redistribuable sans royalties - 1 seul fichier de base de données, idéal pour petite appli monoposte - très très rapide selon les articles que j'ai parcouru - interface avec SQLLite4WD (http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que j'aurais un peu de temps...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
Olivier BONNAURE a écrit :
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par
cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ...
et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/
- Open source et redistribuable sans royalties
- 1 seul fichier de base de données, idéal pour petite appli monoposte
- très très rapide selon les articles que j'ai parcouru
- interface avec SQLLite4WD
(http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que
j'aurais un peu de temps...
A+
--
Romain PETIT
http://cerbermail.com/?IJmancZl88
(cliquez sur le lien ci-dessus pour me contacter en privé)
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/ - Open source et redistribuable sans royalties - 1 seul fichier de base de données, idéal pour petite appli monoposte - très très rapide selon les articles que j'ai parcouru - interface avec SQLLite4WD (http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que j'aurais un peu de temps...
A+
-- Romain PETIT http://cerbermail.com/?IJmancZl88 (cliquez sur le lien ci-dessus pour me contacter en privé)
jacques trepp
Roumegou Eric wrote:
elecoest avait prétendu :
Encore un adepte de l'arrondi "à la louche" ? ;-) Le "kilo" en informatique, c'est 1024...
Désolé mais je pense que tu parles du KibiOctet ;-)
Les anciens parles en 1024, les jeunes parlent en 1000 !
Kilooctet (ko) : Un kilooctet est égal à 1000 octets soit 103 octets. Kibioctet (Ki) : 1024 octets soit 210 octets.
Manu
Voilà une information interressante. J'avoue que c'est la première fois que j'entendais parler de cette appellation (Kibi,Mibi,Gibi) et avoir été souvent dérouté d'un système à l'autre (Ms, novell,linux). Je comprends mieux maintenant.
Ce petit lien qui en dit plus http://www.zonehd.net/news.php?op=lire&nid7
A priori chez Ms, on vend du kilo (10 puissance 3) et chez les autres du kibi ?
bonjour, et alors, les mecs qui ont pondu ça, on les a payés ? sans déconner rofl bonne journée signé : un shadock qui n'aime pas les gibis !
-- Jacques TREPP Albygest
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004
Roumegou Eric wrote:
elecoest avait prétendu :
Encore un adepte de l'arrondi "à la louche" ? ;-)
Le "kilo" en informatique, c'est 1024...
Désolé mais je pense que tu parles du KibiOctet ;-)
Les anciens parles en 1024, les jeunes parlent en 1000 !
Kilooctet (ko) : Un kilooctet est égal à 1000 octets soit 103 octets.
Kibioctet (Ki) : 1024 octets soit 210 octets.
Manu
Voilà une information interressante. J'avoue que c'est la première
fois que j'entendais parler de cette appellation (Kibi,Mibi,Gibi) et
avoir été souvent dérouté d'un système à l'autre (Ms, novell,linux).
Je comprends mieux maintenant.
Ce petit lien qui en dit plus
http://www.zonehd.net/news.php?op=lire&nid7
A priori chez Ms, on vend du kilo (10 puissance 3) et chez les autres
du kibi ?
bonjour,
et alors, les mecs qui ont pondu ça, on les a payés ? sans déconner rofl
bonne journée
signé : un shadock qui n'aime pas les gibis !
--
Jacques TREPP
Albygest
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004
Encore un adepte de l'arrondi "à la louche" ? ;-) Le "kilo" en informatique, c'est 1024...
Désolé mais je pense que tu parles du KibiOctet ;-)
Les anciens parles en 1024, les jeunes parlent en 1000 !
Kilooctet (ko) : Un kilooctet est égal à 1000 octets soit 103 octets. Kibioctet (Ki) : 1024 octets soit 210 octets.
Manu
Voilà une information interressante. J'avoue que c'est la première fois que j'entendais parler de cette appellation (Kibi,Mibi,Gibi) et avoir été souvent dérouté d'un système à l'autre (Ms, novell,linux). Je comprends mieux maintenant.
Ce petit lien qui en dit plus http://www.zonehd.net/news.php?op=lire&nid7
A priori chez Ms, on vend du kilo (10 puissance 3) et chez les autres du kibi ?
bonjour, et alors, les mecs qui ont pondu ça, on les a payés ? sans déconner rofl bonne journée signé : un shadock qui n'aime pas les gibis !
-- Jacques TREPP Albygest
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.601 / Virus Database: 382 - Release Date: 29/02/2004
Olivier BONNAURE
Romain PETIT a écrit :
Olivier BONNAURE a écrit :
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/ - Open source et redistribuable sans royalties - 1 seul fichier de base de données, idéal pour petite appli monoposte - très très rapide selon les articles que j'ai parcouru - interface avec SQLLite4WD (http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que j'aurais un peu de temps...
A+
Je suis bien tenté par SQLite !!! mais c'est pas une appli monoposte ... Et je ne sais pas si c'est aussi performant que HF en multiposte !!
Vivement un accés natif de SQLite ! :)
Romain PETIT a écrit :
Olivier BONNAURE a écrit :
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer
(par cd ou en ligne) donc je vois mal les utilisateurs devoir
installer MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/
- Open source et redistribuable sans royalties
- 1 seul fichier de base de données, idéal pour petite appli monoposte
- très très rapide selon les articles que j'ai parcouru
- interface avec SQLLite4WD
(http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que
j'aurais un peu de temps...
A+
Je suis bien tenté par SQLite !!!
mais c'est pas une appli monoposte ...
Et je ne sais pas si c'est aussi performant que HF en multiposte !!
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/ - Open source et redistribuable sans royalties - 1 seul fichier de base de données, idéal pour petite appli monoposte - très très rapide selon les articles que j'ai parcouru - interface avec SQLLite4WD (http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que j'aurais un peu de temps...
A+
Je suis bien tenté par SQLite !!! mais c'est pas une appli monoposte ... Et je ne sais pas si c'est aussi performant que HF en multiposte !!
Vivement un accés natif de SQLite ! :)
Roumegou Eric
Olivier BONNAURE a présenté l'énoncé suivant :
Romain PETIT a écrit :
Olivier BONNAURE a écrit :
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/ - Open source et redistribuable sans royalties - 1 seul fichier de base de données, idéal pour petite appli monoposte - très très rapide selon les articles que j'ai parcouru - interface avec SQLLite4WD (http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que j'aurais un peu de temps...
A+
Je suis bien tenté par SQLite !!! mais c'est pas une appli monoposte ... Et je ne sais pas si c'est aussi performant que HF en multiposte !!
Tu peux gérer du SQLite en multiposte. Il suffit que ton fichier données sqlite soient sur un serveur de fichiers accèssibles. Mais bon, multipostes tu peux peut être t'orienter quand meme sur du mysql.
Vivement un accés natif de SQLite ! :)
et les accès [alter]natif c'est bien aussi ! Maintes fois indiqué sur ce forum, mais par exemple, moi je travaille avec un seul et meme code au choix sur un sgbd oracle,mysql, sqlite (et d'autres à tester) en utilisant au choix les accès natifs pcsoft ou les accès alternatifs. si c'est pas de l'ouverture ça ;-)
(Voir le site de l'asso)
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
Olivier BONNAURE a présenté l'énoncé suivant :
Romain PETIT a écrit :
Olivier BONNAURE a écrit :
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer
(par cd ou en ligne) donc je vois mal les utilisateurs devoir installer
MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/
- Open source et redistribuable sans royalties
- 1 seul fichier de base de données, idéal pour petite appli monoposte
- très très rapide selon les articles que j'ai parcouru
- interface avec SQLLite4WD
(http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que
j'aurais un peu de temps...
A+
Je suis bien tenté par SQLite !!!
mais c'est pas une appli monoposte ...
Et je ne sais pas si c'est aussi performant que HF en multiposte !!
Tu peux gérer du SQLite en multiposte. Il suffit que ton fichier
données sqlite soient sur un serveur de fichiers accèssibles.
Mais bon, multipostes tu peux peut être t'orienter quand meme sur du
mysql.
Vivement un accés natif de SQLite ! :)
et les accès [alter]natif c'est bien aussi !
Maintes fois indiqué sur ce forum, mais par exemple, moi je travaille
avec un seul et meme code au choix sur un sgbd oracle,mysql, sqlite (et
d'autres à tester) en utilisant au choix les accès natifs pcsoft ou les
accès alternatifs. si c'est pas de l'ouverture ça ;-)
(Voir le site de l'asso)
--
Eric Roumegou
http://cerbermail.com/?Wk2D8D62KI
(cliquez sur le lien ci-dessus pour me contacter en privé)
Je migre de MySQL vers HF car c'est un logiciel que je vais distribuer (par cd ou en ligne) donc je vois mal les utilisateurs devoir installer MySql ... et aussi pour le pb des licences
Tu as essayé SQLLite ? http://www.hwaci.com/sw/sqlite/ - Open source et redistribuable sans royalties - 1 seul fichier de base de données, idéal pour petite appli monoposte - très très rapide selon les articles que j'ai parcouru - interface avec SQLLite4WD (http://rbesset.net/modules/news/article.php?storyid2) ?
J'ai pas encore essayé mais j'ai une forte envie de m'y plonger dès que j'aurais un peu de temps...
A+
Je suis bien tenté par SQLite !!! mais c'est pas une appli monoposte ... Et je ne sais pas si c'est aussi performant que HF en multiposte !!
Tu peux gérer du SQLite en multiposte. Il suffit que ton fichier données sqlite soient sur un serveur de fichiers accèssibles. Mais bon, multipostes tu peux peut être t'orienter quand meme sur du mysql.
Vivement un accés natif de SQLite ! :)
et les accès [alter]natif c'est bien aussi ! Maintes fois indiqué sur ce forum, mais par exemple, moi je travaille avec un seul et meme code au choix sur un sgbd oracle,mysql, sqlite (et d'autres à tester) en utilisant au choix les accès natifs pcsoft ou les accès alternatifs. si c'est pas de l'ouverture ça ;-)
(Voir le site de l'asso)
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
Gégé
> D'autre part, connais-tu beaucoup de Nom ou prénom de 80 caractères ?
Oui avec des noms espagnols
Des adresses de 255 caractères ?
Oui
Des numéros de téléphone de 20 caractères ?
Non
C'est là que l'on regrette le VARCHAR
> D'autre part, connais-tu beaucoup de Nom ou prénom de 80 caractères ?
> D'autre part, connais-tu beaucoup de Nom ou prénom de 80 caractères ?
Oui avec des noms espagnols
Des adresses de 255 caractères ?
Oui
Des numéros de téléphone de 20 caractères ?
Non
C'est là que l'on regrette le VARCHAR
Roumegou Eric
jacques trepp a pensé très fort :
bonjour, et alors, les mecs qui ont pondu ça, on les a payés ? sans déconner rofl bonne journée signé : un shadock qui n'aime pas les gibis !
J'avais voulu la faire celle là.
En fait c'est relativement sérieux car si j'ai bien compris c'est parti d'un abus de langage de notre profession. le kilo, c'est une unité pour 1000 (et la base 10, à priori c'est quand meme plus facile à comprendre) et on l'a utilisé au début cette unité pour exprimer autre chose (avec des puissances de 2)
Moi, je serais plutôt pour le MO à 1000 mais que cela ce généralise tout constructeur et OS.
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
jacques trepp a pensé très fort :
bonjour,
et alors, les mecs qui ont pondu ça, on les a payés ? sans déconner rofl
bonne journée
signé : un shadock qui n'aime pas les gibis !
J'avais voulu la faire celle là.
En fait c'est relativement sérieux car si j'ai bien compris c'est parti
d'un abus de langage de notre profession.
le kilo, c'est une unité pour 1000 (et la base 10, à priori c'est quand
meme plus facile à comprendre) et on l'a utilisé au début cette unité
pour exprimer autre chose (avec des puissances de 2)
Moi, je serais plutôt pour le MO à 1000 mais que cela ce généralise
tout constructeur et OS.
--
Eric Roumegou
http://cerbermail.com/?Wk2D8D62KI
(cliquez sur le lien ci-dessus pour me contacter en privé)
bonjour, et alors, les mecs qui ont pondu ça, on les a payés ? sans déconner rofl bonne journée signé : un shadock qui n'aime pas les gibis !
J'avais voulu la faire celle là.
En fait c'est relativement sérieux car si j'ai bien compris c'est parti d'un abus de langage de notre profession. le kilo, c'est une unité pour 1000 (et la base 10, à priori c'est quand meme plus facile à comprendre) et on l'a utilisé au début cette unité pour exprimer autre chose (avec des puissances de 2)
Moi, je serais plutôt pour le MO à 1000 mais que cela ce généralise tout constructeur et OS.
-- Eric Roumegou http://cerbermail.com/?Wk2D8D62KI (cliquez sur le lien ci-dessus pour me contacter en privé)
STASZEWSKI André
Romain PETIT wrote:
Eric LAURENT avait prétendu :
Olivier BONNAURE a écrit:
voila la table ...
Qui a-t-il de bizarre ? Chaque enregistrement fait 1,85 Ko 600 enregistrements font donc 1,85 X 600 = 1110 Ko = 1,11 Mo
Encore un adepte de l'arrondi "à la louche" ? ;-) Le "kilo" en informatique, c'est 1024...
1 enregistrement = 1858 octets soit 1858/1024 = 1.81 ko
600 enrg = 1858 * 600 = 1114800 octets soit 1114800/1024 ~= 1088 ko 1114800/1024/1024 ~= 1.06 Mo
60000 enrg = 106.3 Mo
A+
Finalement j'avais pas trop mal visé ? ... c'est pas moiiiii qu'irait auuuu stand de tir ... >:-> ... Pour info pour notre ami Olivier, il suffit d'aller faire un tour dans la description du fichier créé pour matérialiser la taille du dit fichier en fonction d'un nombre X d'enregistrements ou de faire une évaluation sur un temps X par rapport à des saisies quasi constantes. -- Cordialement, André STASZEWSKI Nouvelle version de Photo Visu sur www.PlaneteDev.fr.st
Romain PETIT wrote:
Eric LAURENT avait prétendu :
Olivier BONNAURE <soli@netcourrier.com> a écrit:
voila la table ...
Qui a-t-il de bizarre ?
Chaque enregistrement fait 1,85 Ko
600 enregistrements font donc 1,85 X 600 = 1110 Ko = 1,11 Mo
Encore un adepte de l'arrondi "à la louche" ? ;-)
Le "kilo" en informatique, c'est 1024...
1 enregistrement = 1858 octets soit 1858/1024 = 1.81 ko
600 enrg = 1858 * 600 = 1114800 octets soit
1114800/1024 ~= 1088 ko
1114800/1024/1024 ~= 1.06 Mo
60000 enrg = 106.3 Mo
A+
Finalement j'avais pas trop mal visé ?
... c'est pas moiiiii qu'irait auuuu stand de tir ... >:-> ...
Pour info pour notre ami Olivier, il suffit d'aller faire un tour dans la
description du fichier créé pour matérialiser la taille du dit fichier en
fonction d'un nombre X d'enregistrements ou de faire une évaluation sur un
temps X par rapport à des saisies quasi constantes.
--
Cordialement,
André STASZEWSKI
Nouvelle version de Photo Visu sur www.PlaneteDev.fr.st
Qui a-t-il de bizarre ? Chaque enregistrement fait 1,85 Ko 600 enregistrements font donc 1,85 X 600 = 1110 Ko = 1,11 Mo
Encore un adepte de l'arrondi "à la louche" ? ;-) Le "kilo" en informatique, c'est 1024...
1 enregistrement = 1858 octets soit 1858/1024 = 1.81 ko
600 enrg = 1858 * 600 = 1114800 octets soit 1114800/1024 ~= 1088 ko 1114800/1024/1024 ~= 1.06 Mo
60000 enrg = 106.3 Mo
A+
Finalement j'avais pas trop mal visé ? ... c'est pas moiiiii qu'irait auuuu stand de tir ... >:-> ... Pour info pour notre ami Olivier, il suffit d'aller faire un tour dans la description du fichier créé pour matérialiser la taille du dit fichier en fonction d'un nombre X d'enregistrements ou de faire une évaluation sur un temps X par rapport à des saisies quasi constantes. -- Cordialement, André STASZEWSKI Nouvelle version de Photo Visu sur www.PlaneteDev.fr.st
