IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 MySQL Discussion :

debutant - "question de cours" VARCHAR et BLOB


Sujet :

MySQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juin 2006
    Messages : 6
    Par défaut debutant - "question de cours" VARCHAR et BLOB
    bonjour,
    hormis la lecture je pense que mes questions ne sont pas compliquées.
    tout d'abord je n'ai que peu de rapport avec le monde des bases de données. J'ai des rudiments en programmation objet (c++ essentiellement) et par hobbyisme j'aimerai faire un site avec base de données. Au travers de mes lectures sur le sujet, certaines zones d'ombres sont apparues. Ces questions etant surement tres basique je n'y ai pas lu d'eclaircissement sur le net. Voici donc les quelques interrogations qui me hantent :

    Tout d'abord la difference entre varchar(taille) et text/blob :

    si j'ai bien compris les text/blob voient leur taille allouée dynamiquement et les varchar sont fixé lors de la creation de la table. Ainsi un varchar(250) verra ttes les instances de la table avec une taille fixe de 250 caractere. alors que le mm chp blob s'adaptera a la donnée (jusqu'a sa limite de stockage). Si c'est bien le cas pourquoi encore utiliser les varchar. Sachant que selon votre faq mysql un text/blob ne consomme que 1 à 4 octets.

    Concernant les tailles maintenant :

    Si je veux utiliser un tinyInt unsigned je peux aller de 0 à 255 je crois. Mais si je ne veux aller que de 0 à 25 ? dois je limiter la taille? et est ce reellement souhaitable ?

    Concernant la limitation en taille des types simples :

    Si je "declare" un varchar(30) la chaine correspondante aura une longueur de 30 caracteres, jusque la je comprends. Suivant la même logique si je declare un smallint(2) unsigned je peux aller de 0 à 99?
    Mais dans l'optique d'un indice qui ne pourra jamais depasse la valeur 55. Est ce que pouvoir aller jusqu'a 99 est un gachis de place? ou plus vraisemblablement le codage permettant d'aller jusqu'a la dizaine fait que niveau place cela ne change rien.

    Cette question concerne le lien entre deux tables ayant un nb d'instances totalement different :

    Admettons que j'ai une table produit, qui au final fera apparaitre dans les 1000 produits et une table typePrix qui n'aura que deux instances. Cela signifie que quelque soit le produit, il n'aura le choix qu'entre deux prix.
    A chaque creation d'un produit, dois je créer un prix (ne pouvant avoir que deux valeur?) ou peut on faire pointer 500 produit vers le prix d'id 1 et les 500 autres vers l'autre l'instance typeprix? Ou existe il une maniere plus efficace? Est ce dans ce genre de cas que l'utilisation d'un enum ou d'un set peut etre pertinent?

    Question liée au text/blob

    Les deux peuvent etre nuls et gerent les chaines. La difference est que le blob est sensible a la casse. Dans le cas d'une recherche dans la base, cela impose à l'utilisateur d'etre plus vigilant. N'est pas preferable pour nous (par soucis de commodité) d'ajouter plus de souplesse dans les recherches ?

    J'ai encore de nombreuses interrogations mais je ne souhaite pas rendre mon post encore plus illisbles. Ces questions sont peut etre suprenante ou etranges mais je n'ai pas une formation informatique et encore moins en base de données. Donc n'ayant pas suivi de cours tout est nouveaux pour moi.
    Heureusement qu'il existe de nombreuses ressources en ligne tres claire et completes

    Merci d'avance.

    ps: ma formation consistait en du webdesign d'ou les rudiments en programmation et merise.

  2. #2
    Expert confirmé
    Avatar de Swoög
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    6 045
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 6 045
    Par défaut
    Citation Envoyé par le_chainon_manquant
    Tout d'abord la difference entre varchar(taille) et text/blob :

    si j'ai bien compris les text/blob voient leur taille allouée dynamiquement et les varchar sont fixé lors de la creation de la table. Ainsi un varchar(250) verra ttes les instances de la table avec une taille fixe de 250 caractere. alors que le mm chp blob s'adaptera a la donnée (jusqu'a sa limite de stockage). Si c'est bien le cas pourquoi encore utiliser les varchar. Sachant que selon votre faq mysql un text/blob ne consomme que 1 à 4 octets.
    parce que, les soucis de taille mis à part, il est bien plus efficace de gérer une table dont la taille de chaque ligne est fixe plutôt que dynamique...

    Concernant les tailles maintenant :

    Si je veux utiliser un tinyInt unsigned je peux aller de 0 à 255 je crois. Mais si je ne veux aller que de 0 à 25 ? dois je limiter la taille? et est ce reellement souhaitable ?
    non, de toutes façons, la limitation n'existe qu'à l'affichage pour les types numériques, il n'y a pas de limitation possible au niveau de l'espace de stockage, exceptés celles définies par les types proposés (tiny/small/normal/long)

    Concernant la limitation en taille des types simples :

    Si je "declare" un varchar(30) la chaine correspondante aura une longueur de 30 caracteres, jusque la je comprends. Suivant la même logique si je declare un smallint(2) unsigned je peux aller de 0 à 99?
    Mais dans l'optique d'un indice qui ne pourra jamais depasse la valeur 55. Est ce que pouvoir aller jusqu'a 99 est un gachis de place? ou plus vraisemblablement le codage permettant d'aller jusqu'a la dizaine fait que niveau place cela ne change rien.
    encore une fois, il s'agit simplement d'une limitation à l'affichage, aucun impact sur le stockage

    Cette question concerne le lien entre deux tables ayant un nb d'instances totalement different :

    Admettons que j'ai une table produit, qui au final fera apparaitre dans les 1000 produits et une table typePrix qui n'aura que deux instances. Cela signifie que quelque soit le produit, il n'aura le choix qu'entre deux prix.
    A chaque creation d'un produit, dois je créer un prix (ne pouvant avoir que deux valeur?) ou peut on faire pointer 500 produit vers le prix d'id 1 et les 500 autres vers l'autre l'instance typeprix? Ou existe il une maniere plus efficace? Est ce dans ce genre de cas que l'utilisation d'un enum ou d'un set peut etre pertinent?
    Si les deux types sont destinés à ne jamais évolués et son très simple (une seule donnée caractérise chacun des types), alors je pense que le choix du set/enum est meilleur dans ce cas

    Personnellement, je n'utilise set ou enum que pour des choix hyper simple (de type oui/non) qui sont destinés à ne pas évoluer... sinon la liaison est beaucoup plus pratique...

    Question liée au text/blob

    Les deux peuvent etre nuls et gerent les chaines. La difference est que le blob est sensible a la casse. Dans le cas d'une recherche dans la base, cela impose à l'utilisateur d'etre plus vigilant. N'est pas preferable pour nous (par soucis de commodité) d'ajouter plus de souplesse dans les recherches ?
    Les blobs sont surtout faits pour stocker des données binaires, alors que les text le sont pour du texte...

    ensuite, ça dépend du charset et de la COLLATION utilisée pour le champ...

    de plus, tu peux également modifier ces paramètres lors de la recherche (attention : c'est très couteux en performances...)
    Rédacteur "éclectique" (XML, Cours PHP, Cours JavaScript, IRC, Web...)
    Les Règles du Forum - Mon Site Web sur DVP.com (Développement Web, PHP, (X)HTML/CSS, SQL, XML, IRC)
    je ne répondrai à aucune question technique via MP, MSN ou Skype : les Forums sont là pour ça !!! Merci de me demander avant de m'ajouter à vos contacts sinon je bloque !
    pensez à la balise [ code ] (bouton #) et au tag :resolu: (en bas)

  3. #3
    Membre du Club
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juin 2006
    Messages : 6
    Par défaut
    Merci pour la reponse rapide

    Citation Envoyé par Swoög
    parce que, les soucis de taille mis à part, il est bien plus efficace de gérer une table dont la taille de chaque ligne est fixe plutôt que dynamique...
    Je ne comprends pas cette partie. A quel niveau cela affecte la gestion d'une table. Et pourquoi les tables ayant des champs dynamiques sont plus compliqués a gerer que les autres? Hormis cette gestion cela ne change pas la vitesse a laquelle on peut acceder au champs si? D'apres la faq c'est un point dont on aurait pas a se soucier. bref rapidité d'acces inchangé mais place moindre. Le pb est donc la gestion mais je ne comprends pas quelle notion ce mot recouvre en bdd.

    Citation Envoyé par Swoög
    non, de toutes façons, la limitation n'existe qu'à l'affichage pour les types numériques, il n'y a pas de limitation possible au niveau de l'espace de stockage, exceptés celles définies par les types proposés (tiny/small/normal/long)

    encore une fois, il s'agit simplement d'une limitation à l'affichage, aucun impact sur le stockage
    Donc les smallint(2) par exemple n'existent que par souçis esthetique ?

    Citation Envoyé par Swoög
    Si les deux types sont destinés à ne jamais évolués et son très simple (une seule donnée caractérise chacun des types), alors je pense que le choix du set/enum est meilleur dans ce cas

    Personnellement, je n'utilise set ou enum que pour des choix hyper simple (de type oui/non) qui sont destinés à ne pas évoluer... sinon la liaison est beaucoup plus pratique...
    On peut penser que certains produits peuvent etre soumis a un troisieme prix donc la gestion dans une table est pertinente ici ?

    Citation Envoyé par Swoög
    Les blobs sont surtout faits pour stocker des données binaires, alors que les text le sont pour du texte...

    ensuite, ça dépend du charset et de la COLLATION utilisée pour le champ...

    de plus, tu peux également modifier ces paramètres lors de la recherche (attention : c'est très couteux en performances...)
    charset et collation je ne sais pas ce que cela signifie. Je suis réellement debutant. Merci pour tes réponses, j'avais naivement pensé que mes questions donnaient lieu a des reponses plus tranchées. Manifestement tout est une question de choix et de compromis.

  4. #4
    Expert confirmé
    Avatar de Swoög
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    6 045
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 6 045
    Par défaut
    Citation Envoyé par le_chainon_manquant
    Je ne comprends pas cette partie. A quel niveau cela affecte la gestion d'une table. Et pourquoi les tables ayant des champs dynamiques sont plus compliqués a gerer que les autres? Hormis cette gestion cela ne change pas la vitesse a laquelle on peut acceder au champs si? D'apres la faq c'est un point dont on aurait pas a se soucier. bref rapidité d'acces inchangé mais place moindre. Le pb est donc la gestion mais je ne comprends pas quelle notion ce mot recouvre en bdd.
    Alors, supposons qu'on ait une table, et qu'on veuille selectionner un champ pour chaque enregistrement...

    si les enregistrements sont de tailles fixes, pas de problèmes : on va au premier enregistrement, on récupère la valeur, on avance de la taille d'un enregistrement, on récupère la valeur, etc...
    toutes ces opérations se font avec des calculs fixes donc très rapides...

    alors que s'il y a des champs de taille dynamiques, il faudra à chaque fois s'arretter au début des champs de taille dynamiques, récupérer la taille (accès fichier), faire le nouveau calcul, etc...
    ceci demande beaucoup plus de lectures dans le fichier, et donc beaucoup plus de temps, les performances se dégradent très vite...

    à l'opposé, si toutes les valeurs font la même taille ou presque (exemple entre 240 et 260 caractères) il est beaucoup plus performant d'avoir des tailles fixes, et la perte est minime (20 caractères par enregistrement au maximum)

    Donc les smallint(2) par exemple n'existent que par souçis estetique ?
    oui, ça n'a absoluement aucun impact sur l'espace prit dans le fichier pour le stockage, à contrario, int(2) et smallint(2) ne représente pas le même espace de stockage... [même si généralement, MySQL transformera le int(2) en smallint à la création de la table]


    On peut penser que certains produits peuvent etre soumis a un troisieme prix donc la gestion dans une table est pertinente ici ?
    dans ce cas, (si les types peuvent être modifiés, ajoutés, etc...) l'utilisation d'une table annexe servant aux liaisons est bien plus judicieux, de plus, ça permet de donner plus d'informations sur les types qu'un simple chaîne de caractères...

    charset et collation je ne sais pas ce que cela signifie. Je suis réellement debutant.
    le charset (ou encoding) est la table de caractères utilsée pour stocker le texte... les plus connues sont l'ISO-8859-1, ISO-8859-15 (appellées aussi latin1 et latin9) et UTF-8

    la collation est un ensemble de règles permettant de comparer deux caractères...

    le plus simple est la comparaison pur du code du caractère, les plus complexes, mettent en jeu la casse ('a' = 'A'), certains traitements des accents ('é' = 'e') etc...

    plus d'infos sur ces points : http://dev.mysql.com/doc/refman/4.1/en/charset.html (en anglais, désolé, pas de version FR pour ces versions de MySQL)

    Merci pour tes réponses, j'avais naivement pensé que mes questions donnaient lieu a des reponses plus tranchées. Manifestement tout est une question de choix et de compromis.
    en fait il n'y a pas vraiment de réponses général, tout est à voir au cas par cas, puisque tu as fait de la modélisation OO, tu peux le comprendre, on ne peut pas dire l'héritage est mieux que la composition, ça dépend au cas par cas, la modélisation des BDD relève des même problèmes
    Rédacteur "éclectique" (XML, Cours PHP, Cours JavaScript, IRC, Web...)
    Les Règles du Forum - Mon Site Web sur DVP.com (Développement Web, PHP, (X)HTML/CSS, SQL, XML, IRC)
    je ne répondrai à aucune question technique via MP, MSN ou Skype : les Forums sont là pour ça !!! Merci de me demander avant de m'ajouter à vos contacts sinon je bloque !
    pensez à la balise [ code ] (bouton #) et au tag :resolu: (en bas)

  5. #5
    Expert confirmé
    Avatar de qi130
    Homme Profil pro
    Expert Processus IT
    Inscrit en
    Mars 2003
    Messages
    3 932
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 64
    Localisation : France

    Informations professionnelles :
    Activité : Expert Processus IT
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2003
    Messages : 3 932
    Par défaut
    Ainsi un varchar(250) verra ttes les instances de la table avec une taille fixe de 250 caractere.
    Attention au mélange des genres dans cette formulation...

    Avec un varchar(250), la longueur maxi admissible est bien 250, mais si on désire stocker 100, seuls 100 octets seront utilisés (hormis celui dédié à la mémorisation de la longueur).
    C'est ce phénomène qui rend plus couteux l'utilisation des varchar: à chaque ligne le sgbd doit lire la longueur effective de la chaine stockée dans le varchar avant de la restituer.
    Par contre, on économise en terme d'occupation; ce qui n'est bien sûr pas le cas avec un CHAR(250) pour lequel les 250 octets sont utilisés, même si on y met 100 caractères.

  6. #6
    Expert confirmé
    Avatar de Swoög
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    6 045
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 6 045
    Par défaut
    merci qi130 !!

    (je confond tout le temps char et varchar à ce niveau lol)
    Rédacteur "éclectique" (XML, Cours PHP, Cours JavaScript, IRC, Web...)
    Les Règles du Forum - Mon Site Web sur DVP.com (Développement Web, PHP, (X)HTML/CSS, SQL, XML, IRC)
    je ne répondrai à aucune question technique via MP, MSN ou Skype : les Forums sont là pour ça !!! Merci de me demander avant de m'ajouter à vos contacts sinon je bloque !
    pensez à la balise [ code ] (bouton #) et au tag :resolu: (en bas)

  7. #7
    Membre du Club
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juin 2006
    Messages : 6
    Par défaut
    Re bonjour,
    Merci pour les precisions et éclaircissement mais cela me fait me poser d'autres questions :

    Je pensais que varchar reservait une certaine place au contraire du text/blob mais selon qi130 seul char reserve "en dur" en fonction du critere de taille qu'on lui adjoint. varchar allouerai donc de la taille dynamiquement jusqu'a la limite qu'on lui a fixé (varchar ne peut depasser 255 octets je crois). La grande difference entre texte/blob et varchar serait donc cette limite ? (ie text/blob ne souffrent pas de cette limite). Et comment, en pouvant stocker plus, les text/blob "consomment" moins?

    Pour revenir a l'usage de text et de blob. Leur seul critere de taille serait donc des "decarations de type" tel que longtext/tinytext... et blob se destine principalement au stockage de données binaires. Quel est donc l'interet de gerer la casse sur blob et non pas sur text?

    J'ai une derniere question, un peu plus pragmatique. Pour mon site je dois utiliser mysql 3.23. Afin de gagner en vitesse de consultation j'ai decidé au maximum d'utiliser des types char plutot que varchar. Ainsi mes noms et prenoms d'utilisateur ou encore leur adresse mail...sont des char(30)/(40)... mais surprise en reconsultant les champs ces derniers sont devenus des varchar(30)/(40). Par defaut mysql deciderait donc d'optimiser la gestion de l'espace ? Pour information j'utilise donc la version 1.6 d'easyphp.

    Je pense avoir fait le tour de mes questions concernant ce sujet. L'utilisation de mysql m'a fait m'interroger sur son fonctionnement. Je pense qu'une fois que j'aurai lu suffisament de docs je reposterai pour d'eventuelles precisions.

    Encore merci et bonne journée.

    varchar et char j'aurai quand meme pu m'en rendre compte plus tot

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [Debutant] Nouvelle question sur les pointeurs
    Par etiennegaloup dans le forum Débuter
    Réponses: 3
    Dernier message: 11/01/2006, 09h55
  2. [Debutant] Question sur Cours SQL Pro
    Par etiennegaloup dans le forum Langage SQL
    Réponses: 5
    Dernier message: 25/10/2005, 09h50
  3. [debutant STL] question sur les vectors
    Par killerjeff dans le forum SL & STL
    Réponses: 13
    Dernier message: 19/08/2004, 17h32
  4. [LG]J'ai honte : question de cours sur les paramètres
    Par letibdesneiges dans le forum Langage
    Réponses: 14
    Dernier message: 17/01/2004, 13h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo