[Résolu] Est-il bon d'utiliser le type text en SQL ?

Bonjour à tous !

Dans la base de données WordPress, on retrouve des types text et longtext, pour par exemple post_title et post_content.
Voila j'ai cru voir quelque part (je n'arrive plus à mettre la main sur cette ressource) que le type text en SQL est à éviter car il est obsolète. Est-ce vrai ?

Et quelle alternative correcte dois-je utiliser pour un champ dont je ne connaîtrait pas la longueur ?

Merci d'avance.

Il n'y a que deux possibilités :

blob et text en mysql

L'article explique bien la différence entre les deux. (mais je n'ai jamais entendu parler d'obsolescence de l'un ou de l'autre)

Je n'ai jamais entendu de problème d'obsolescence.
Par contre ce qu'il faut prendre ne compte c'est qu'un champ texte peut contenir virtuellement un nombre infini de caractères de toutes sortes.
( Je ne sais pas quels sont les limites, mais il faut retenir que c'est fait pour de très longs textes.)

Du coup on peut imaginer n'importe quoi, des caractères qui provoquerais des bogues ou des problèmes de fonctionnement plus grave, voir même des risques de sécurité, puisqu'il n'y a pas de limite de taille et donc de la longueur d'un script malveillant ...

partant de ce constat, on imagine bien que pour un simple prénom ou même un nom, on peut se permettre d'utiliser un type de champ qui n'accepterais que des caractères alphabétiques avec un nombre de caractères limité.
Un varchar de 255 caractères est déjà bien large, j'imagine très mal un nom ou un prénom qui soit aussi long …

Mais bon, on peut tout simplement parler de SQL, et dire qu'il faut adapter chaque champ à son contenu; un nombre, une suite alphanumérique, un long texte, du contenu brut, une date, … etc

Merci pour vos réponses.
Je crois que l'info concernait SQL Server... mais je ne suis pas sûr.

En termes de performances, qu'en est-il pour le type text ou varchar ?

Promis après j'en ai fini avec mes questions.

En gros, il y a 6 types de stockage de chaînes (si on excepte set et enum) :

(var)char, (var)binary, text et blob

Différence char/varchar : le premier est de longueur fixe, pas le second. ("abc" dans un char(4) sera encodé "abc "; dans un varchar(4) "abcd")

Différence binary/varbinary : même chose

Différence (var)binary/(var)char : (var)binary est une limitation en octet,(var)char est une limitation en nombre de caractère

Différence text/blob : une valeur TEXT est une valeur BLOB insensible à la casse.

Différence text/blob - (var)char/(var)binary : les seconds ont une taille maximale; sur les premiers, ça dépend de la mémoire et de la configuration du serveur.


En fonction des besoins, tu utilises les champs que t'as besoin ^^

Raphi a écrit :

Je crois que l'info concernait SQL Server... mais je ne suis pas sûr.

LONGTEXT est un type MySQL, et non SQL. Peut-être est-ce lié au fait que TEXT, en SQL Server, ne peut pas gérer de l'unicode ou de l'utf-8 et qui faut utiliser NTEXT à la place?

themagicdavid a écrit :
Par contre ce qu'il faut prendre ne compte c'est qu'un champ texte peut contenir virtuellement un nombre infini de caractères de toutes sortes.
( Je ne sais pas quels sont les limites, mais il faut retenir que c'est fait pour de très longs textes.)

Contrairement à d'autres DB, les TEXT(ou les BLOB correspondants qui ont les même tailles) en mysql ont des limites finies, c'est pour cette raison que l'on a plusieurs tailles:

TINYTEXT    2^8-1             255  255 b
TEXT        2^16-1         65 535  64 Ki
MEDIUMTEXT  2^24-1     16 777 215  16 Mi
LONGTEXT    2^32-1  4 294 967 295  4 Gi

À noter que cela donne le nombre de caractères pour du stockage en 8-bits (ASCII, iso-8852-…), cela diminuera pour de l'utf8 et autres encodage unicode.
La limite pour TEXT est certes assez grande, mais on peut très vite l'atteindre tout de même…
Modifié par kustolovic (11 Dec 2013 - 13:08)

QuentinC a écrit :
A noter aussi au niveau des performances que char est logiquement plus rapide que varchar lui-même plus rapide que text/blob, et que les derniers ne peuvent sauf erreur pas être indexés (sauf en fulltext mais c'est pour une utilisation radicalement différente).

char sera plus lourd (en terme de mémoire) que varchar si le string est plus petit que la taille maximale (vu que char va combler les espaces).

Et text/blob peuvent être indexé (depuis mysql 3.5), mais l'index ne se fera que sur les x premiers caractères (octets ?).

Lothindil a écrit :

char sera plus lourd que varchar si le string est plus petit que la taille maximale (vu que char va combler les espaces).

Il y a des langages auxquels je suis totalement hermétique, mais qui me font quand même prendre de joyeux fous rires

Pardon pour le hs, je ferai pénitence et acte de repentir Vendredÿ en ne postant pas

QuentinC a écrit :
J'ajouterais aussi que char/varchar sont limités à un maximum de 255 caractères quoi qu'il arrive, i.e. varchar(256) ne fonctionnera pas.

La limite de varchar en octets et de 65 535. La limite de 255 octets date de plusieurs années, je ne sais plus à partir de quelle version elle est obsolète et j'ai la flemme de chercher.

QuentinC a écrit :
A noter aussi au niveau des performances que char est logiquement plus rapide que varchar lui-même plus rapide que text/blob, et que les derniers ne peuvent sauf erreur pas être indexés (sauf en fulltext mais c'est pour une utilisation radicalement différente).

Tu mélanges tout. Je ne sais pas de quelle "rapidité" tu parles mais si tu parles de la recherche de texte ça dépend surtout du type d'encodage utilisé et pas du type CHAR ou VARCHAR. La recherche FULLTEXT ne fonctionne qu'avec MyIsam mais depuis quelques temps je pense que personne n'utilise encore ce moteur.

6l20 a écrit :
Pardon pour le hs, je ferai pénitence et acte de repentir Vendredÿ en ne postant pas

Oh ben non Vendredÿ passé était carrément nul, faut se fair plaisir

6l20 a écrit :
A noter aussi au niveau des performances que char est logiquement plus rapide que varchar lui-même plus rapide que text/blob, et que les derniers ne peuvent sauf erreur pas être indexés (sauf en fulltext mais c'est pour une utilisation radicalement différente).

Comme jb_gfx, je rajouterais que TEXT/BLOB peuvent être indexés (depuis la 3.jesaisplus), mais qu'il faut obligatoirement spécifier une taille d'index.

Pour ce qui est des performances, on distingue déjà les choix pour la taille de la base de données et pour sa rapidité de réponse aux requêtes/opérations. Pour ce dernier point le choix du stockage peut être dépendant du type de requête que l'on veut effectuer et prioriser. Mais bon, dans les cas courants on s'en fiche un peu de ces détails, et sinon on fait appel à un expert

Pour tous ceux qui ne le sont pas, suivre des principes «de base» qui consiste à choisir le stockage qui correspond le mieux à notre type de donnée suffit. D'autant plus que bien choisir ses types permet de mieux en comprendre la nature d'une colonne sans devoir en analyser le contenu, et de limiter intentionnellement l'utilisation.

CHAR: Idéalement pour des données qui sont (majoritairement) de même taille : codes, hash, références produit alphanumérique, etc.
VARCHAR: Des données textes à longueur variable, mais qui restent dans des tailles moindres et dans une variation limitée: noms, rue, ville, modèle, téléphone, email, etc.
TEXT/BLOB: pour des textes que l'on ne souhaite pas limiter: corps d'article, données linéarisées, etc.
Modifié par kustolovic (11 Dec 2013 - 21:20)

Merci beaucoup pour vos réponses !
Entre ce que j'ai appris en cours, ce qu'on m'a dit et ce que j'ai fait, j'étais un peu pommé sur certaines notions. Donc là ça devient beaucoup plus clair merci à tous pour vos réponses !

a écrit :
La limite de varchar en octets et de 65 535. La limite de 255 octets date de plusieurs années, je ne sais plus à partir de quelle version elle est obsolète et j'ai la flemme de chercher.

Ah, autant pour moi, je ne savais pas... le premier MySQL que j'ai touché était la 3.22.

a écrit :
La recherche FULLTEXT ne fonctionne qu'avec MyIsam mais depuis quelques temps je pense que personne n'utilise encore ce moteur.

Si, moi... justement pour avoir fulltext. Mais évidemment que sur les tables le nécéssitant, toutes les autres sont en innoDB.

A noter que MySQL 5.6 supportera fulltext sur les tables innoDB. Mais je ne peux pas encore l'avoir pour le moment.
Modifié par QuentinC (12 Dec 2013 - 09:08)