peut-on intégrer le zéro initial, par exemple pour un code postal ou un
numéro de téléphone, dans MySQL (en le stockant ou en sortie, mais en
gardant un champ numérique) ou mieux vaut-il gérer ça avec la langage
qui s'occupera de la présentation ?
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
Antoun
OK, malgré la remarque de Antoun - que je note -, je vais passer en char. J'ai la manie de vouloir tout mettre au millimètre, même quand c'est inutile. Ainsi, je vais chercher une liste exhaustive de prénoms pour savoir de quel longueur max sera mon champ prénom... J'essaie de me soigner :)
et si tu n'as, au pire, que des Jean-Paul, que feras-tu le jour où un Timothée-Balthazar débarquera ?
OK, malgré la remarque de Antoun - que je note -, je vais passer en
char. J'ai la manie de vouloir tout mettre au millimètre, même quand
c'est inutile. Ainsi, je vais chercher une liste exhaustive de prénoms
pour savoir de quel longueur max sera mon champ prénom... J'essaie de me
soigner :)
et si tu n'as, au pire, que des Jean-Paul, que feras-tu le jour où un
Timothée-Balthazar débarquera ?
OK, malgré la remarque de Antoun - que je note -, je vais passer en char. J'ai la manie de vouloir tout mettre au millimètre, même quand c'est inutile. Ainsi, je vais chercher une liste exhaustive de prénoms pour savoir de quel longueur max sera mon champ prénom... J'essaie de me soigner :)
et si tu n'as, au pire, que des Jean-Paul, que feras-tu le jour où un Timothée-Balthazar débarquera ?
Olivier Masson
Antoun a écrit :
et si tu n'as, au pire, que des Jean-Paul, que feras-tu le jour où un Timothée-Balthazar débarquera ?
Ah, ah, c'était sans compter sur mes prévision de prénoms (et noms, de plus en plus courants) composés ! :) Sans rire, je perds du temps à voir si je vais mettre un VARCHAR(40) ou un CHAR(30) sur le champs 'trucmuche' : est-ce qu'un tel choix (gardons les 2 options que j'ai cité) peu engendrer de grosses différences au niveau de la taille de la base et du temps des requêtes sur 1000 enregistrements, 10000, 100000 ?
Antoun a écrit :
et si tu n'as, au pire, que des Jean-Paul, que feras-tu le jour où un
Timothée-Balthazar débarquera ?
Ah, ah, c'était sans compter sur mes prévision de prénoms (et noms, de
plus en plus courants) composés ! :)
Sans rire, je perds du temps à voir si je vais mettre un VARCHAR(40) ou
un CHAR(30) sur le champs 'trucmuche' : est-ce qu'un tel choix (gardons
les 2 options que j'ai cité) peu engendrer de grosses différences au
niveau de la taille de la base et du temps des requêtes sur 1000
enregistrements, 10000, 100000 ?
et si tu n'as, au pire, que des Jean-Paul, que feras-tu le jour où un Timothée-Balthazar débarquera ?
Ah, ah, c'était sans compter sur mes prévision de prénoms (et noms, de plus en plus courants) composés ! :) Sans rire, je perds du temps à voir si je vais mettre un VARCHAR(40) ou un CHAR(30) sur le champs 'trucmuche' : est-ce qu'un tel choix (gardons les 2 options que j'ai cité) peu engendrer de grosses différences au niveau de la taille de la base et du temps des requêtes sur 1000 enregistrements, 10000, 100000 ?
Patrick Mevzek
Le Fri, 18 Aug 2006 10:46:59 +0200, Olivier Masson a écrit :
Sans rire, je perds du temps à voir si je vais mettre un VARCHAR(40) ou un CHAR(30) sur le champs 'trucmuche' : est-ce qu'un tel choix (gardons les 2 options que j'ai cité) peu engendrer de grosses différences au niveau de la taille de la base et du temps des requêtes sur 1000 enregistrements, 10000, 100000 ?
CHAR() est surtout un héritage du passé, où les contraintes techniques faisaient que les cases devaient être fixées en longueur. Maintenant, il y a vraiment très peu de cas de figure où il a un sens, ie où l'on a des chaînes uniquement et rigoureusement toutes de la même taille.
En particulier, dans votre cas de figure, si c'est bien toujours stocker des prénoms, CHAR() serait un bien mauvais choix selon moi.
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple gère les deux de la même façon, donc mêmes performances. Ce qui fait qu'on préférera alors quasimment systématiquement TEXT.
Après, au niveau de la taille de la base cela ne changera pas grand chose, les deux doivent être codés en gros pareil : stockage de la taille + du contenu.
Mais bon rien ne peut remplacer des tests avec votre jeu spécifique de données et votre SGBDR et sa configuration logicielle et matérielle.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Fri, 18 Aug 2006 10:46:59 +0200, Olivier Masson a écrit :
Sans rire, je perds du temps à voir si je vais mettre un VARCHAR(40) ou
un CHAR(30) sur le champs 'trucmuche' : est-ce qu'un tel choix (gardons
les 2 options que j'ai cité) peu engendrer de grosses différences au
niveau de la taille de la base et du temps des requêtes sur 1000
enregistrements, 10000, 100000 ?
CHAR() est surtout un héritage du passé, où les contraintes techniques
faisaient que les cases devaient être fixées en longueur.
Maintenant, il y a vraiment très peu de cas de figure où il a un sens,
ie où l'on a des chaînes uniquement et rigoureusement toutes de la même
taille.
En particulier, dans votre cas de figure, si c'est bien toujours stocker
des prénoms, CHAR() serait un bien mauvais choix selon moi.
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences
notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple
gère les deux de la même façon, donc mêmes performances. Ce qui fait
qu'on préférera alors quasimment systématiquement TEXT.
Après, au niveau de la taille de la base cela ne changera pas grand
chose, les deux doivent être codés en gros pareil : stockage de la
taille + du contenu.
Mais bon rien ne peut remplacer des tests avec votre jeu spécifique de
données et votre SGBDR et sa configuration logicielle et matérielle.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Fri, 18 Aug 2006 10:46:59 +0200, Olivier Masson a écrit :
Sans rire, je perds du temps à voir si je vais mettre un VARCHAR(40) ou un CHAR(30) sur le champs 'trucmuche' : est-ce qu'un tel choix (gardons les 2 options que j'ai cité) peu engendrer de grosses différences au niveau de la taille de la base et du temps des requêtes sur 1000 enregistrements, 10000, 100000 ?
CHAR() est surtout un héritage du passé, où les contraintes techniques faisaient que les cases devaient être fixées en longueur. Maintenant, il y a vraiment très peu de cas de figure où il a un sens, ie où l'on a des chaînes uniquement et rigoureusement toutes de la même taille.
En particulier, dans votre cas de figure, si c'est bien toujours stocker des prénoms, CHAR() serait un bien mauvais choix selon moi.
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple gère les deux de la même façon, donc mêmes performances. Ce qui fait qu'on préférera alors quasimment systématiquement TEXT.
Après, au niveau de la taille de la base cela ne changera pas grand chose, les deux doivent être codés en gros pareil : stockage de la taille + du contenu.
Mais bon rien ne peut remplacer des tests avec votre jeu spécifique de données et votre SGBDR et sa configuration logicielle et matérielle.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Thierry Boudet
On 2006-08-18, Patrick Mevzek wrote:
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple gère les deux de la même façon, donc mêmes performances. Ce qui fait qu'on préférera alors quasimment systématiquement TEXT.
Sauf qu'on peut fixer une taille limite au VARCHAR, ce qui peut parfois être un bon garde-fou.
-- David Lightman: What is the primary goal? Joshua: You should know, Professor. You programmed me. David Lightman: C'mon. What is the primary goal? Joshua: To win the game.
On 2006-08-18, Patrick Mevzek <pm-N200608@nospam.dotandco.com> wrote:
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences
notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple
gère les deux de la même façon, donc mêmes performances. Ce qui fait
qu'on préférera alors quasimment systématiquement TEXT.
Sauf qu'on peut fixer une taille limite au VARCHAR, ce qui
peut parfois être un bon garde-fou.
--
David Lightman: What is the primary goal?
Joshua: You should know, Professor. You programmed me.
David Lightman: C'mon. What is the primary goal?
Joshua: To win the game.
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple gère les deux de la même façon, donc mêmes performances. Ce qui fait qu'on préférera alors quasimment systématiquement TEXT.
Sauf qu'on peut fixer une taille limite au VARCHAR, ce qui peut parfois être un bon garde-fou.
-- David Lightman: What is the primary goal? Joshua: You should know, Professor. You programmed me. David Lightman: C'mon. What is the primary goal? Joshua: To win the game.
Patrick Mevzek
Le Fri, 18 Aug 2006 13:31:08 +0000, Thierry Boudet a écrit :
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple gère les deux de la même façon, donc mêmes performances. Ce qui fait qu'on préférera alors quasimment systématiquement TEXT.
Sauf qu'on peut fixer une taille limite au VARCHAR, ce qui peut parfois être un bon garde-fou.
Sauf que, Murphy aidant, quelque soit la limite qu'on fixe, parfois on aura besoin de la dépasser :-)
Donc dès qu'on a le moindre doute -> TEXT, si cela n'a pas d'impact négatif sur les performances du SGBDR.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Fri, 18 Aug 2006 13:31:08 +0000, Thierry Boudet a écrit :
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences
notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple
gère les deux de la même façon, donc mêmes performances. Ce qui fait
qu'on préférera alors quasimment systématiquement TEXT.
Sauf qu'on peut fixer une taille limite au VARCHAR, ce qui
peut parfois être un bon garde-fou.
Sauf que, Murphy aidant, quelque soit la limite qu'on fixe, parfois on
aura besoin de la dépasser :-)
Donc dès qu'on a le moindre doute -> TEXT, si cela n'a pas d'impact
négatif sur les performances du SGBDR.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
<http://www.dotandco.net/ressources/icann_registrars/details/index>
Le Fri, 18 Aug 2006 13:31:08 +0000, Thierry Boudet a écrit :
Reste donc VARCHAR() et TEXT. Il n'y a pas nécessairement de différences notables entre les deux, cela dépend du SGBDR. PostgreSQL par exemple gère les deux de la même façon, donc mêmes performances. Ce qui fait qu'on préférera alors quasimment systématiquement TEXT.
Sauf qu'on peut fixer une taille limite au VARCHAR, ce qui peut parfois être un bon garde-fou.
Sauf que, Murphy aidant, quelque soit la limite qu'on fixe, parfois on aura besoin de la dépasser :-)
Donc dès qu'on a le moindre doute -> TEXT, si cela n'a pas d'impact négatif sur les performances du SGBDR.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> <http://www.dotandco.net/ressources/icann_registrars/details/index>
Olivier Masson
Patrick Mevzek a écrit :
Sauf que, Murphy aidant, quelque soit la limite qu'on fixe, parfois on aura besoin de la dépasser :-)
Donc dès qu'on a le moindre doute -> TEXT, si cela n'a pas d'impact négatif sur les performances du SGBDR.
Bon, j'abandonne définitivement le CHAR partout alors :) Merci.
Patrick Mevzek a écrit :
Sauf que, Murphy aidant, quelque soit la limite qu'on fixe, parfois on
aura besoin de la dépasser :-)
Donc dès qu'on a le moindre doute -> TEXT, si cela n'a pas d'impact
négatif sur les performances du SGBDR.
Bon, j'abandonne définitivement le CHAR partout alors :) Merci.
