par défaut mes champs textes font 255 carac de long; sachant que pour
certaines zones il suffit de 10 ou 15 , est il préférable de mettre les
vraies tailles maxi ?
Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution
(surtout ça qui m'importe) ?
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre l es vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
Merci
Patrick
Il est toujours préférable de mettre les tailles maxi (10 ou 15)
plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne
sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients,
tu comprendras la différence de poids pour ton appli rien que pour 1
champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront
très bien ton champ de 255 carac simplement parce qu'ils sont plus
puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés
chacuns sous 8 bits (255*8=2040 bits) alors que l'on peut n'en
réserver que 10 (10*8=80 bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi
lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour
certaines zones il suffit de 10 ou 15 , est il préférable de mettre l es
vraies tailles maxi ?
Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution
(surtout ça qui m'importe) ?
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre l es vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
Merci
Patrick
...Patrick
Ok merci, je pensais un peu ça .. Je suppose que je peux donc y gagner au niveau vitesse ... J'ai 4 tables pricinpales: celles des articles: +/- 75000 articles (4 champs) (juste de la consultation) celles des entrees actuellements 37000 records 16 champs (ajout de données tous les jours) celles des commande à recevoir: 36000 records et 26 champs (consultations) et celle des article en réservation 3500 records et 24 champs je dois donc penser à leur longueurs car dans une liste déroulante , sur un champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" a écrit dans le message de news:
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre les vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
Merci
Patrick
Ok merci, je pensais un peu ça ..
Je suppose que je peux donc y gagner au niveau vitesse ...
J'ai 4 tables pricinpales:
celles des articles: +/- 75000 articles (4 champs) (juste de la
consultation)
celles des entrees actuellements 37000 records 16 champs (ajout de données
tous les jours)
celles des commande à recevoir: 36000 records et 26 champs (consultations)
et celle des article en réservation 3500 records et 24 champs
je dois donc penser à leur longueurs car dans une liste déroulante , sur un
champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" <brainburnt@gmail.com> a écrit dans le message de news:
1154410184.064704.142680@75g2000cwc.googlegroups.com...
Il est toujours préférable de mettre les tailles maxi (10 ou 15)
plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne
sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients,
tu comprendras la différence de poids pour ton appli rien que pour 1
champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront
très bien ton champ de 255 carac simplement parce qu'ils sont plus
puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés
chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en
réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi
lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour
certaines zones il suffit de 10 ou 15 , est il préférable de mettre les
vraies tailles maxi ?
Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution
(surtout ça qui m'importe) ?
Ok merci, je pensais un peu ça .. Je suppose que je peux donc y gagner au niveau vitesse ... J'ai 4 tables pricinpales: celles des articles: +/- 75000 articles (4 champs) (juste de la consultation) celles des entrees actuellements 37000 records 16 champs (ajout de données tous les jours) celles des commande à recevoir: 36000 records et 26 champs (consultations) et celle des article en réservation 3500 records et 24 champs je dois donc penser à leur longueurs car dans une liste déroulante , sur un champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" a écrit dans le message de news:
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre les vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
Merci
Patrick
brainburnt
si tu fais une liste déroulante, tu as peut-être intérêt d'affiner un peut tes recherches avant de faire ta liste. Par exemple imagine que tu ait une table client, à ce moment, tu demande à l'utilisateur de choisir le sexe de la personne à rechercher, du coup tu n'aura plus que la moitié (par exemple) de tes records dans la liste, donc un gain de temps (en plus d'ajuster la longueur de tes champs). ...Patrick wrote:
Ok merci, je pensais un peu ça .. Je suppose que je peux donc y gagner au niveau vitesse ... J'ai 4 tables pricinpales: celles des articles: +/- 75000 articles (4 champs) (juste de la consultation) celles des entrees actuellements 37000 records 16 champs (ajout de donn ées tous les jours) celles des commande à recevoir: 36000 records et 26 champs (consultatio ns) et celle des article en réservation 3500 records et 24 champs je dois donc penser à leur longueurs car dans une liste déroulante , sur un champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" a écrit dans le message de news:
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre les vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
Merci
Patrick
si tu fais une liste déroulante, tu as peut-être intérêt d'affiner
un peut tes recherches avant de faire ta liste. Par exemple imagine que
tu ait une table client, à ce moment, tu demande à l'utilisateur de
choisir le sexe de la personne à rechercher, du coup tu n'aura plus
que la moitié (par exemple) de tes records dans la liste, donc un gain
de temps (en plus d'ajuster la longueur de tes champs).
...Patrick wrote:
Ok merci, je pensais un peu ça ..
Je suppose que je peux donc y gagner au niveau vitesse ...
J'ai 4 tables pricinpales:
celles des articles: +/- 75000 articles (4 champs) (juste de la
consultation)
celles des entrees actuellements 37000 records 16 champs (ajout de donn ées
tous les jours)
celles des commande à recevoir: 36000 records et 26 champs (consultatio ns)
et celle des article en réservation 3500 records et 24 champs
je dois donc penser à leur longueurs car dans une liste déroulante , sur un
champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" <brainburnt@gmail.com> a écrit dans le message de news:
1154410184.064704.142680@75g2000cwc.googlegroups.com...
Il est toujours préférable de mettre les tailles maxi (10 ou 15)
plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne
sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients,
tu comprendras la différence de poids pour ton appli rien que pour 1
champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront
très bien ton champ de 255 carac simplement parce qu'ils sont plus
puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés
chacuns sous 8 bits (255*8=2040 bits) alors que l'on peut n'en
réserver que 10 (10*8=80 bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi
lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour
certaines zones il suffit de 10 ou 15 , est il préférable de mettre les
vraies tailles maxi ?
Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution
(surtout ça qui m'importe) ?
si tu fais une liste déroulante, tu as peut-être intérêt d'affiner un peut tes recherches avant de faire ta liste. Par exemple imagine que tu ait une table client, à ce moment, tu demande à l'utilisateur de choisir le sexe de la personne à rechercher, du coup tu n'aura plus que la moitié (par exemple) de tes records dans la liste, donc un gain de temps (en plus d'ajuster la longueur de tes champs). ...Patrick wrote:
Ok merci, je pensais un peu ça .. Je suppose que je peux donc y gagner au niveau vitesse ... J'ai 4 tables pricinpales: celles des articles: +/- 75000 articles (4 champs) (juste de la consultation) celles des entrees actuellements 37000 records 16 champs (ajout de donn ées tous les jours) celles des commande à recevoir: 36000 records et 26 champs (consultatio ns) et celle des article en réservation 3500 records et 24 champs je dois donc penser à leur longueurs car dans une liste déroulante , sur un champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" a écrit dans le message de news:
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre les vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
Merci
Patrick
...Patrick
Ok mais ici, il s'agit de choisir parmi une liste de 75000 articles qui sont susceptibles d'entrer en stock dans nos magasin à un moment ou l'autre, je dois donc les avoir tous dans la liste; une autre liste dans un autre formulaire peut avoir 2500 à 3500 records. J'ai ausi des requetes de 45000 records.. En fait tout ça vient de SAP mais vu la lourdeur et manque de souplesse des écrans, on refait certaines precédures propres à notre service sur access. Patrick
"brainburnt" a écrit dans le message de news:
si tu fais une liste déroulante, tu as peut-être intérêt d'affiner un peut tes recherches avant de faire ta liste. Par exemple imagine que tu ait une table client, à ce moment, tu demande à l'utilisateur de choisir le sexe de la personne à rechercher, du coup tu n'aura plus que la moitié (par exemple) de tes records dans la liste, donc un gain de temps (en plus d'ajuster la longueur de tes champs). ...Patrick wrote:
Ok merci, je pensais un peu ça .. Je suppose que je peux donc y gagner au niveau vitesse ... J'ai 4 tables pricinpales: celles des articles: +/- 75000 articles (4 champs) (juste de la consultation) celles des entrees actuellements 37000 records 16 champs (ajout de données tous les jours) celles des commande à recevoir: 36000 records et 26 champs (consultations) et celle des article en réservation 3500 records et 24 champs je dois donc penser à leur longueurs car dans une liste déroulante , sur un champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" a écrit dans le message de news:
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre les vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
Merci
Patrick
Ok mais ici, il s'agit de choisir parmi une liste de 75000 articles qui sont
susceptibles d'entrer en stock dans nos magasin à un moment ou l'autre, je
dois donc les avoir tous dans la liste;
une autre liste dans un autre formulaire peut avoir 2500 à 3500 records.
J'ai ausi des requetes de 45000 records..
En fait tout ça vient de SAP mais vu la lourdeur et manque de souplesse des
écrans, on refait certaines precédures propres à notre service sur access.
Patrick
"brainburnt" <brainburnt@gmail.com> a écrit dans le message de news:
1154497744.500200.80310@i42g2000cwa.googlegroups.com...
si tu fais une liste déroulante, tu as peut-être intérêt d'affiner
un peut tes recherches avant de faire ta liste. Par exemple imagine que
tu ait une table client, à ce moment, tu demande à l'utilisateur de
choisir le sexe de la personne à rechercher, du coup tu n'aura plus
que la moitié (par exemple) de tes records dans la liste, donc un gain
de temps (en plus d'ajuster la longueur de tes champs).
...Patrick wrote:
Ok merci, je pensais un peu ça ..
Je suppose que je peux donc y gagner au niveau vitesse ...
J'ai 4 tables pricinpales:
celles des articles: +/- 75000 articles (4 champs) (juste de la
consultation)
celles des entrees actuellements 37000 records 16 champs (ajout de données
tous les jours)
celles des commande à recevoir: 36000 records et 26 champs (consultations)
et celle des article en réservation 3500 records et 24 champs
je dois donc penser à leur longueurs car dans une liste déroulante , sur
un
champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" <brainburnt@gmail.com> a écrit dans le message de news:
1154410184.064704.142680@75g2000cwc.googlegroups.com...
Il est toujours préférable de mettre les tailles maxi (10 ou 15)
plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne
sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients,
tu comprendras la différence de poids pour ton appli rien que pour 1
champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront
très bien ton champ de 255 carac simplement parce qu'ils sont plus
puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés
chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en
réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi
lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour
certaines zones il suffit de 10 ou 15 , est il préférable de mettre les
vraies tailles maxi ?
Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution
(surtout ça qui m'importe) ?
Ok mais ici, il s'agit de choisir parmi une liste de 75000 articles qui sont susceptibles d'entrer en stock dans nos magasin à un moment ou l'autre, je dois donc les avoir tous dans la liste; une autre liste dans un autre formulaire peut avoir 2500 à 3500 records. J'ai ausi des requetes de 45000 records.. En fait tout ça vient de SAP mais vu la lourdeur et manque de souplesse des écrans, on refait certaines precédures propres à notre service sur access. Patrick
"brainburnt" a écrit dans le message de news:
si tu fais une liste déroulante, tu as peut-être intérêt d'affiner un peut tes recherches avant de faire ta liste. Par exemple imagine que tu ait une table client, à ce moment, tu demande à l'utilisateur de choisir le sexe de la personne à rechercher, du coup tu n'aura plus que la moitié (par exemple) de tes records dans la liste, donc un gain de temps (en plus d'ajuster la longueur de tes champs). ...Patrick wrote:
Ok merci, je pensais un peu ça .. Je suppose que je peux donc y gagner au niveau vitesse ... J'ai 4 tables pricinpales: celles des articles: +/- 75000 articles (4 champs) (juste de la consultation) celles des entrees actuellements 37000 records 16 champs (ajout de données tous les jours) celles des commande à recevoir: 36000 records et 26 champs (consultations) et celle des article en réservation 3500 records et 24 champs je dois donc penser à leur longueurs car dans une liste déroulante , sur un champ des articles qui est dans un formulaire, c'est tres lent..
Merci
"brainburnt" a écrit dans le message de news:
Il est toujours préférable de mettre les tailles maxi (10 ou 15) plutôt que 255 par défault.
Imagine que ton champs soit un numéro de téléphone de client qui ne sont que francais (donc 10 chiffres) imagine que tu aie 1000 clients, tu comprendras la différence de poids pour ton appli rien que pour 1 champ client.
Maintenant, il est vrai que les ordinateurs d'aujourd'hui supporteront très bien ton champ de 255 carac simplement parce qu'ils sont plus puissants qu'autrefois et que la mémoire n'est plus un problème.
Mais par principe, pourquoi réserver 255 caractères qui sont encodés chacuns sous 8 bits (255*8 40 bits) alors que l'on peut n'en réserver que 10 (10*8€ bits).
Voila en gros la raison qui fait que tu doit définir une taille maxi lorsque tu crées ta base...
...Patrick wrote:
Bonsoir,
par défaut mes champs textes font 255 carac de long; sachant que pour certaines zones il suffit de 10 ou 15 , est il préférable de mettre les vraies tailles maxi ? Est ce que j'y gagne au niveau poids de fichier ou vitesse d'exécution (surtout ça qui m'importe) ?
