debutant - "question de cours" VARCHAR et BLOB [Résolu]

[le_chainon_manquant]

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.

[Swoög]

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...)

[le_chainon_manquant]

Merci pour la reponse rapide

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.

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 ?

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 ?

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.

[Swoög]

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

[qi130]

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.

[Swoög]

merci qi130 !!

(je confond tout le temps char et varchar à ce niveau lol)

[le_chainon_manquant]

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