Discussion :

[CHoule]

Bonjour,

La cie ou je travaille vient de signer un contrat avec un client en chine

Donc quelque questions par rapport a SQL Server

1- Est-ce qu'il est nécessaire de convertir les champs de type varchar et char en nvarchar et nchar?

2- Si oui, qu'en est-il des BD en production?

3- Que peut représenter l'impact de cette modification sur les performances?

Cette dernière question m'inquiète particulièrement, puisque nous avons déjà des problèmes de performance (Deadlock) chez certain client. Problème qui pourrait facilement être corrigé en investissant un peu de temps a la correction des processus en place Mais comme le temps c'est de l'argent....

[taibag]

Bonjour,

pour stocker du text chinois tu doit convertir tes colonnes vers unicode nvarchar , pour ce faire :
- suavgarder votre base
-ajouter une colonne null nvarchar à votre table.
- faire un update de ta colonne vers cette derniere.
-supprimer l'ancianne colonne et renommer la nouvelle.
-rebuid tes index.

[SQLpro]

Bonjour,

La cie ou je travaille vient de signer un contrat avec un client en chine

Donc quelque questions par rapport a SQL Server

1- Est-ce qu'il est nécessaire de convertir les champs de type varchar et char en nvarchar et nchar?

Vous vous trompez :
CHAR => NCHAR
VARCHAR => NVARCHAR
Impératif

2- Si oui, qu'en est-il des BD en production?

Étant, je le suppose en CHAR/VARCHAR, vous ne pourrez jamais y mettre du chinois.

3- Que peut représenter l'impact de cette modification sur les performances?

Un accroissement potentiel de Log(2) si index et de 2 si pas d'index des performances, mais surtout un volume x 2 sur toutes les colonnes littérales

Cette dernière question m'inquiète particulièrement, puisque nous avons déjà des problèmes de performance (Deadlock) chez certain client. Problème qui pourrait facilement être corrigé en investissant un peu de temps a la correction des processus en place Mais comme le temps c'est de l'argent....

Les problèmes de deadlocks sont généralement dues à une mauvaise modélisation de la base accouplé à une gestion des transactions souvent mal pensée (niveau d'isolation inadéquat, durée trop longue.....).
Le fait d'utiliser des NATIONAL [VAR]CHAR ne vas pas arranger la chose, mais c'est surtout la concurrence qui est importante dans ce cas.

Lisez le livre que j'ai écrit sur SQL Server (www.amazon.fr/dp/2212135920). Vous y trouverez un chapitre de 36 pages (16) qui parle de cela.
Lisez aussi cet article : http://blog.developpez.com/sqlpro/p1...mances_petites
Enfin, sachez que certains outils de développement comme les ORM (le pire étant hibernate) génère ce genre de chose parce qu'ils pissent un SQL catastrophique. Là aussi lisez moi : http://sqlpro.developpez.com/cours/b...s-epaisses.pdf


A +

[CHoule]

Bonjour et merci de votre réponse.

Étant, je le suppose en CHAR/VARCHAR, vous ne pourrez jamais y mettre du chinois.

Ma question par rapport au BD en production est surtout par rapport au schéma.

IL faut donc un script de mise a niveau pour les champs

- VarChar() / NVarChar
- Text / NText
- Char()/ NChar

Ainsi que l’adaptation des VUES / PROCÉDURES / FONCTIONS

Est-ce qu'un shrink du fichier de log serait approprié?

Merci encore

[SQLpro]

Bonjour et merci de votre réponse.




Ma question par rapport au BD en production est surtout par rapport au schéma.

IL faut donc un script de mise a niveau pour les champs

- VarChar() / NVarChar
- Text / NText
- Char()/ NChar

Ainsi que l’adaptation des VUES / PROCÉDURES / FONCTIONS

Est-ce qu'un shrink du fichier de log serait approprié?

Merci encore

Text et Ntext sont des types obsolètes depuis plus de 10 ans !!!!
Ils sont à remplacer par VARCHAR(max) / NVARCHAR(max).
De même que le type IMAGE => VARBINARY(max)

Enfin, si vous aviez utilisé des types (CREATE TYPE) au lieu de travailler directement avec les types SQL, ceci aurait été grandement facilité.

Encore plus aisé (quelques secondes de transformation) si vous aviez utilisé un outil de modélisation comme Power AMC

A +

[elsuket]

Ainsi que l’adaptation des VUES / PROCÉDURES / FONCTIONS

Est-ce qu'un shrink du fichier de log serait approprié?

En ce qui concerne l'adaptation des vues et fonctions, effectivement il est nécessaire de tout revoir.
Un rétrécissement du fichier du journal des transactions ne doit être réalisé que lorsqu'on dispose de peu d'espace disque, ou que l'on réalise une opération exceptionnelle de maintenance de données ou d'index; cela est-il en relation avec les transformations que vous devez réaliser ?

@++