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
Fred BROUARD
1) un varchar est stocké avec une information supplémentaire : sa longeur réelle. Il est placé en queue de l'enregistrement physique.
2) varchar2 n'existe pas c'est une bidouille Oracle.
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de place que VARCHAR qui est codé en ASCII.
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR pour des petites longeurs fortement remplies et particulièrement si les données sont fréquemment mis à jour.
5) donner une taille proche de la réalité signifie que l'on comprend le modèle. De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8 000 octets. En systématisant des varchar dont on ne maitrise pas la taille réelle on risque vite ce genre d'effet de bord.
A +
hell a écrit:
Bonjour,
j'ai un peu de mal a differencier (choisir) entre les differents types varchar, varchar2, nvarchar et nvarchar2, quelqu'un peut m'éclairer?
De plus y a t-il reelement des impacts a declarer un varchar(255) à la place d'un varchar(50)? si oui lesquels?
Merci, Eric
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
1) un varchar est stocké avec une information supplémentaire : sa longeur
réelle. Il est placé en queue de l'enregistrement physique.
2) varchar2 n'existe pas c'est une bidouille Oracle.
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de place
que VARCHAR qui est codé en ASCII.
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR pour
des petites longeurs fortement remplies et particulièrement si les données sont
fréquemment mis à jour.
5) donner une taille proche de la réalité signifie que l'on comprend le modèle.
De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8 000
octets. En systématisant des varchar dont on ne maitrise pas la taille réelle on
risque vite ce genre d'effet de bord.
A +
hell a écrit:
Bonjour,
j'ai un peu de mal a differencier (choisir) entre les differents types
varchar, varchar2, nvarchar et nvarchar2, quelqu'un peut m'éclairer?
De plus y a t-il reelement des impacts a declarer un varchar(255) à la place
d'un varchar(50)? si oui lesquels?
Merci,
Eric
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
1) un varchar est stocké avec une information supplémentaire : sa longeur réelle. Il est placé en queue de l'enregistrement physique.
2) varchar2 n'existe pas c'est une bidouille Oracle.
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de place que VARCHAR qui est codé en ASCII.
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR pour des petites longeurs fortement remplies et particulièrement si les données sont fréquemment mis à jour.
5) donner une taille proche de la réalité signifie que l'on comprend le modèle. De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8 000 octets. En systématisant des varchar dont on ne maitrise pas la taille réelle on risque vite ce genre d'effet de bord.
A +
hell a écrit:
Bonjour,
j'ai un peu de mal a differencier (choisir) entre les differents types varchar, varchar2, nvarchar et nvarchar2, quelqu'un peut m'éclairer?
De plus y a t-il reelement des impacts a declarer un varchar(255) à la place d'un varchar(50)? si oui lesquels?
Merci, Eric
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
hell
[...]
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de
place
que VARCHAR qui est codé en ASCII.
Ok donc certains caractères ne peuvent être stockés avec des varchars (c'est bien ca?)
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR
pour
des petites longeurs fortement remplies et particulièrement si les données
sont
fréquemment mis à jour.
Bien sur mais pour des données mises à jour assez peu freqement, je prefère minimiser l'espace disque occupé.
5) donner une taille proche de la réalité signifie que l'on comprend le
modèle.
De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8
000
octets. En systématisant des varchar dont on ne maitrise pas la taille
réelle on
risque vite ce genre d'effet de bord.
D'accord, mis a part cet aspect là, y a t'il d'autres impacts entre un varchar(50) et un varchar(255) dans la mesure où on est sur de ne pas depasser les 8Ko?
Merci de tes reponses a+
[...]
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de
place
que VARCHAR qui est codé en ASCII.
Ok donc certains caractères ne peuvent être stockés avec des varchars (c'est
bien ca?)
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR
pour
des petites longeurs fortement remplies et particulièrement si les données
sont
fréquemment mis à jour.
Bien sur mais pour des données mises à jour assez peu freqement, je prefère
minimiser l'espace disque occupé.
5) donner une taille proche de la réalité signifie que l'on comprend le
modèle.
De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8
000
octets. En systématisant des varchar dont on ne maitrise pas la taille
réelle on
risque vite ce genre d'effet de bord.
D'accord, mis a part cet aspect là, y a t'il d'autres impacts entre un
varchar(50) et un varchar(255) dans la mesure où on est sur de ne pas
depasser les 8Ko?
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de
place
que VARCHAR qui est codé en ASCII.
Ok donc certains caractères ne peuvent être stockés avec des varchars (c'est bien ca?)
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR
pour
des petites longeurs fortement remplies et particulièrement si les données
sont
fréquemment mis à jour.
Bien sur mais pour des données mises à jour assez peu freqement, je prefère minimiser l'espace disque occupé.
5) donner une taille proche de la réalité signifie que l'on comprend le
modèle.
De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8
000
octets. En systématisant des varchar dont on ne maitrise pas la taille
réelle on
risque vite ce genre d'effet de bord.
D'accord, mis a part cet aspect là, y a t'il d'autres impacts entre un varchar(50) et un varchar(255) dans la mesure où on est sur de ne pas depasser les 8Ko?
Merci de tes reponses a+
Fred BROUARD
hell a écrit:
[...]
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de
place
que VARCHAR qui est codé en ASCII.
Ok donc certains caractères ne peuvent être stockés avec des varchars (c'est bien ca?)
C'est plus complqiué que cela : dépend du jeux de caractères et de la collation.
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR
pour
des petites longeurs fortement remplies et particulièrement si les données
sont
fréquemment mis à jour.
Bien sur mais pour des données mises à jour assez peu freqement, je prefère minimiser l'espace disque occupé.
Donc augmenter la durée des requêtes et le volume des pages à lire => perf médiocres
5) donner une taille proche de la réalité signifie que l'on comprend le
modèle.
De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8
000
octets. En systématisant des varchar dont on ne maitrise pas la taille
réelle on
risque vite ce genre d'effet de bord.
D'accord, mis a part cet aspect là, y a t'il d'autres impacts entre un varchar(50) et un varchar(255) dans la mesure où on est sur de ne pas depasser les 8Ko?
Oui, un non respect de la sémantique du modèle !
Merci de tes reponses a+
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
hell a écrit:
[...]
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de
place
que VARCHAR qui est codé en ASCII.
Ok donc certains caractères ne peuvent être stockés avec des varchars (c'est
bien ca?)
C'est plus complqiué que cela : dépend du jeux de caractères et de la collation.
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR
pour
des petites longeurs fortement remplies et particulièrement si les données
sont
fréquemment mis à jour.
Bien sur mais pour des données mises à jour assez peu freqement, je prefère
minimiser l'espace disque occupé.
Donc augmenter la durée des requêtes et le volume des pages à lire => perf médiocres
5) donner une taille proche de la réalité signifie que l'on comprend le
modèle.
De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8
000
octets. En systématisant des varchar dont on ne maitrise pas la taille
réelle on
risque vite ce genre d'effet de bord.
D'accord, mis a part cet aspect là, y a t'il d'autres impacts entre un
varchar(50) et un varchar(255) dans la mesure où on est sur de ne pas
depasser les 8Ko?
Oui, un non respect de la sémantique du modèle !
Merci de tes reponses
a+
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
3) NVARCHAR signifie un codage en UNICODE et occupe donc deux fois plus de
place
que VARCHAR qui est codé en ASCII.
Ok donc certains caractères ne peuvent être stockés avec des varchars (c'est bien ca?)
C'est plus complqiué que cela : dépend du jeux de caractères et de la collation.
4) les varchar/nvarchar sont contreperformant par rapport aux CHAR/NCHAR
pour
des petites longeurs fortement remplies et particulièrement si les données
sont
fréquemment mis à jour.
Bien sur mais pour des données mises à jour assez peu freqement, je prefère minimiser l'espace disque occupé.
Donc augmenter la durée des requêtes et le volume des pages à lire => perf médiocres
5) donner une taille proche de la réalité signifie que l'on comprend le
modèle.
De plus SQL Server 2000 ne peut insérer des lignes de table dépassant 8
000
octets. En systématisant des varchar dont on ne maitrise pas la taille
réelle on
risque vite ce genre d'effet de bord.
D'accord, mis a part cet aspect là, y a t'il d'autres impacts entre un varchar(50) et un varchar(255) dans la mesure où on est sur de ne pas depasser les 8Ko?
Oui, un non respect de la sémantique du modèle !
Merci de tes reponses a+
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
