[MySQL] Différence entre varchar nvarchar
Fermé
Dumbo
-
bredsky -
bredsky -
Bonjour tout le monde,
J'ai fait quelques recherches et j'ai vu que la différence entre ces deux types de données était leur jeu de caractères. Varchar est un type de données NON UNICODE contrairement à nvarchar qui est UNICODE.
De plus, avec le type de données nvarchar, un caractère est stocké sur 2 octets (1 octet pour varchar).
Donc au final, nvarchar pourra stocker 2 fois moins de caractères que varchar.
Ai-je bien tout compris ? Ou j'ai oublié quelques détails important ?
J'ai fait quelques recherches et j'ai vu que la différence entre ces deux types de données était leur jeu de caractères. Varchar est un type de données NON UNICODE contrairement à nvarchar qui est UNICODE.
De plus, avec le type de données nvarchar, un caractère est stocké sur 2 octets (1 octet pour varchar).
Donc au final, nvarchar pourra stocker 2 fois moins de caractères que varchar.
Ai-je bien tout compris ? Ou j'ai oublié quelques détails important ?
A voir également:
- Différence entre varchar et nvarchar
- Mysql nvarchar - Meilleures réponses
- Difference nvarchar varchar - Meilleures réponses
- Différence entre tcp et udp - Guide
- Difference entre million et milliard - Accueil - Technologies
- Difference entre mode avion et donnees mobiles - Guide
- Difference entre mo et mb - Forum Matériel & Système
- Difference actif et en ligne messenger - Forum Facebook Messenger
4 réponses
Bonjour,
Alternate : ca n'est pas tout à fait cela, en fait, par défaut, MySQL accepte une entrée de 200 caractères dans un VARCHAR(50) MAIS il la tronque à 50 caractères ...
C'est donc dangereux, parce que on croit que tout s'est bien passé (il n'y a ni erreur ni warning), MAIS on a perdu 150 caractères :)
Cela peut se configurer dans le my.cnf (strict sql mode), mais c'est très rarement en place ...
Voir la documentation : https://dev.mysql.com/doc/refman/8.0/en/char.html
Dumbo : NVARCHAR n'existe pas en tant que type de données dans MySQL ... par contre, cela existe sur SQL Server ... confusion ? :)
Du coup, elle peut exister également dans certaines couches d'abstraction (JDBC, ...) : MySQL l'assimilera alors aux VARCHAR.
Bon courage
Alternate : ca n'est pas tout à fait cela, en fait, par défaut, MySQL accepte une entrée de 200 caractères dans un VARCHAR(50) MAIS il la tronque à 50 caractères ...
C'est donc dangereux, parce que on croit que tout s'est bien passé (il n'y a ni erreur ni warning), MAIS on a perdu 150 caractères :)
Cela peut se configurer dans le my.cnf (strict sql mode), mais c'est très rarement en place ...
Voir la documentation : https://dev.mysql.com/doc/refman/8.0/en/char.html
Dumbo : NVARCHAR n'existe pas en tant que type de données dans MySQL ... par contre, cela existe sur SQL Server ... confusion ? :)
Du coup, elle peut exister également dans certaines couches d'abstraction (JDBC, ...) : MySQL l'assimilera alors aux VARCHAR.
Bon courage
c'est a peu prêt cela. mais pour palier au problème du nombre de caractères, on peut toujours augmenter la taille du varchar ou du nvarchar pour qu'ils acceptent autant de caractère que tu le souhaites.
exemple : ici on choisit le nombre de caractères,
exemple : ici on choisit le nombre de caractères,
CREATE TABLE `exemple` ( `id` VARCHAR( 10 ) NOT NULL , `plop` VARCHAR( 255 ) NOT NULL , PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Bah varchar pourra aller au maximum à 8000 tant dit que nvarchar à 4000 non ?
"C'est a peu prêt cela."
C'est à dire qu'il manque certains détails non ? lol
En fait je demande ça car je dois changer un type de données varchar en nvarchar et je voudrai savoir si cela peut avoir des conséquences ou pas.
"C'est a peu prêt cela."
C'est à dire qu'il manque certains détails non ? lol
En fait je demande ça car je dois changer un type de données varchar en nvarchar et je voudrai savoir si cela peut avoir des conséquences ou pas.
j'utilise régulièrement mySQL et j'ai vu que quelques fois lorsque qu'il y avait un champ varchar(50) et que, par le biais d'une application web (ou autre), on y introduisait un texte de 100 ou 200 caractères ... ça fonctionnait.
j'avais fait des recherches et j'avais trouvé que les tailles déclarées à la création n'était là que pour l'indexation de la table. en fait MySQL réserve la taille précisée à la création mais s'il a besoin de plus il prend plus.
(j'espère que si tu as des booléen à utiliser, tu ne regarderas pas trop en détail le fonctionnement car là aussi ça semble compliqué)
j'avais fait des recherches et j'avais trouvé que les tailles déclarées à la création n'était là que pour l'indexation de la table. en fait MySQL réserve la taille précisée à la création mais s'il a besoin de plus il prend plus.
(j'espère que si tu as des booléen à utiliser, tu ne regarderas pas trop en détail le fonctionnement car là aussi ça semble compliqué)
oki je comprends mieux :)
je n'utilise pas le MTK, mais essaie de mettre ta colonne VARCHAR en UTF8 pour voir si ca passe mieux ?
je n'utilise pas le MTK, mais essaie de mettre ta colonne VARCHAR en UTF8 pour voir si ca passe mieux ?
En fait, mon soucis, c'est que lorsque je migre ma base SQL Server vers MySQL par l'intermédiaire de l'outil MySQL Migration Toolkit, les données en nvarchar contenant des accents ont bien migré mais celles en varchar (avec des accents) posent un problème. Donc la solution que j'ai trouvé, changer le type de données varchar en nvarchar ...
C'est pour cela qu'avant je souhaite vérifier si cela ne peut entraîner aucune erreur.