Discussion :

[Monstros Velu]

Bonjour,

je dois gérer plusieurs applications ayant chacune une base sur une instance SQL Server 2005. Il se trouve que ces applications sont localisés (Français, Néerlandais, allemand, Polonais). L'application existe (en Anglais, avec une collation à priori de langue anglaise), et je dois la localiser, le plus simplement possible (problèmes de délais)

Se pose donc le problème de la collation. On a plusieurs possibilités :
-Unicode sur l'instance. Mais ça implique pas mal de changement.
-Localisation par pays pour chaque base, avec les différenciations dans les procédures stockées de chaque base pour les tables temporaires
-Western Europe ? Celà inclut-il la Pologne ? j'en doute.

Avez-vous déjà eu ce cas ? Comment l'avez-vous résolu ? Quel est le meilleur moyen de le résoudre ?

[SQLpro]

-Unicode sur l'instance. Mais ça implique pas mal de changement.

Et cela double le volume des données, donc des performances 2 fois moins bonnes...

-Localisation par pays pour chaque base

C'est la bonne approche..

avec les différenciations dans les procédures stockées de chaque base pour les tables temporaires

Si un seul serveur c'est nécessaire. Mais 2 remarques :
1) essayez de minimiser l'utilisation des tables temporaires. Avec 2005, les CTE et la récursivité, vous ne devriez plus avoir besoin d'utiliser des tables temporaires. Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...te-recursives/
De plus votre code restera identique si au lieu de créer vos table temporaire from scratch, vous les créez en SELECT ... INTO ! En effet vos colonnes hériterons de la collation des colonnes du SELECT...

-Western Europe ? Celà inclut-il la Pologne ? j'en doute.

Aucun intérêt.

A +

[Monstros Velu]

Je croyais que les tables temporaires, dans tempdb, utilisaient la collation de l'instance ? Un SELECT ... INTO #matable conservera la collation des colonnes du select quand même ?


edit : question supplémentaire : Les tables temporaires étaient souvent utilisées pour des raisons de performances (suppression de curseur avec une table temporaire et un while en SQL2K, par exemple, ou réduction du nombre de jointures). Est-ce que l'utilisation des "WITH" dans le cas des CTE est aussi performant ? Quid du cas ou une table temporaire était la factorisation d'une jointure et était utilisée plusieurs fois par d'autres jointures pour divers résultats ?

[SQLpro]

Lorsque vous utilisez des tables temporaires, vous obligez SQL Server à écrire physiquement sur les fichiers :

• du journal des transactions de Tempdb
• des données de la base tempdb.

Si vous utilisez des constructions à base de vues ou mieux de CTE vous n'obligez jamais SQL Server à écrire des données dans des fichiers.
Sachant qu'une écriture disque est au minimum 1000 fois plus couteuse que la même opération en mémoire... deduisez vous même ce qu'il faut faire !

A +

[Monstros Velu]

Vu comme ça, c'est sur...

Merci !