Les choix de Collation du serveur SQL
j'ai passé beaucoup de temps ce soir à essayer de trouver des conseils sur le choix de la compilation à appliquer dans mon installation SQL Server 2008 R2, mais presque tout en ligne dit essentiellement "choisir ce qui est bon pour vous."Extrêmement inutile.
Mon contexte est le développement de nouvelles applications. Je ne m'inquiète pas de la rétrocompatibilité avec une version antérieure de SQL Server (viz. < = 2005). Je suis très intéressé par le stockage de données représentant des langues d'environ le globe - pas seulement basé sur le Latin. Le peu d'aide que j'ai trouvé en ligne suggère que je devrais éviter toutes les collations "SQL_". Cela restreint mon choix à l'utilisation d'une collation binaire ou "non binaire" basée sur la locale de Windows.
si j'utilise le binaire, je suppose que je devrais utiliser "BIN2."C'est donc ça ma question. Comment puis-je déterminer si je dois utiliser BIN2 ou tout simplement "Latin1_General_100_XX_XX_XX"? Mon sens de l'Araignée me dit que BIN2 fournira collation qui est "moins précis," mais plus générique pour toutes les langues (et rapide!). Je pense aussi que la compilation binaire est sensible à la casse, sensible à l'accent, et sensible au kana (Oui?). En revanche, je pense que la collation non-binaire fonctionnerait mieux pour les langues basées sur le Latin.
la documentation ne corrobore pas mes affirmations ci-dessus, je fais des suppositions instruites. Mais c'est le problème! Pourquoi la documentation en ligne si mince que le choix est laissé à la conjecture? Même le livre "SQL Server 2008 Internals" a discuté de la variété de choix, sans expliquer pourquoi et quand la collation binaire serait choisie (par rapport à la collation windows non binaire). Criminy!!!
4 réponses
"SQL Server 2008 Internals" a une bonne discussion sur le sujet imho.
la compilation binaire est délicate, si vous avez l'intention de soutenir la recherche de texte pour les êtres humains, vous feriez mieux d'aller avec non-binaire. Binaire est bon pour gagner un tout petit peu de performance si vous avez accordé tout le reste (architecture d'abord) et dans les cas où la sensibilité de cas et la sensibilité d'accent sont un comportement désiré, comme les hachages de mot de passe par exemple. Classement binaire est "plus précis" dans le sens qu'il ne tient pas compte de textes similaires. Les ordres de tri que vous obtenez hors de là sont bons pour les machines seulement si.
il n'y a qu'une légère différence entre les collations SQL_* et les fenêtres natives. Si vous n'êtes pas limité par la compatibilité, allez pour les natifs car ils sont la voie à suivre afaik.
Classement décide de l'ordre de tri et d'égalité. Vous choisissez, ce qui convient vraiment le mieux à vos utilisateurs. Il est entendu que vous utiliserez les types unicode (comme nvarchar) pour vos données pour soutenir le texte international. Collation affecte ce qui peut être stocké dans une colonne non-unicode, qui ne vous affecte pas alors.
ce qui importe vraiment, c'est que vous évitiez de mélanger les collations dans la clause WHERE parce que c'est là que vous payez l'amende en n'utilisant pas d'index. Afaik il n'y a pas de collation Silver bullet pour supporter toutes les langues. Vous pouvez choisir un pour la majorité de vos utilisateurs ou aller dans le soutien de localisation avec la colonne différente pour chaque langue.
une chose importante est d'avoir la collation du serveur la même que la collation de votre base de données. Il vous facilitera la vie si vous prévoyez d'utiliser des tables temporaires comme des tables temporaires si elles sont créées avec "CREATE TABLE #ttt..."récupérez la collation du serveur et vous rencontrerez des conflits de collation que vous devrez résoudre en spécifiant une collation explicite. Cela a aussi un impact sur le rendement.
veuillez ne pas considérer ma réponse comme complète, mais vous devriez prendre en considération les points suivants:
- (comme dit par #Anthony) tous les champs de texte doivent utiliser
nvarchartype de données. Cela vous permettra de stocker n'importe quel personnage de n'importe quelle langue, tel que défini parUTF-8\unicodejeu de caractères! Si vous ne le faites pas, vous ne pourrez pas mélanger des textes de différentes origines (latin, cyrillique, arabe, etc.) dans vos tableaux.
ceci dit, votre choix de collation touchent principalement les suivantes:
- la séquence de collage, ou les règles de tri à définir entre des caractères tels que " e " et "é", Ou " c " et " ç " (doivent-elles être considérées comme égales ou non?). Dans certains cas, les séquences de collation prennent en compte des combinaisons de lettres spécifiques, tout comme en Hongrois, où C et CS, ou D, DZ et DZS, sont considérés indépendamment.
- la façon dont les espaces (ou autres caractères autres que les lettres) sont analysés: lequel est le "alphabétique" correct l'ordre?
celui-ci (les espaces sont considérés comme des caractères de premier rang)?
San Juan
San Teodoro
Santa Barbara
ou celui-ci (les espaces ne sont pas considérées dans l'ordre)?
San Juan
Santa Barbara
San Teodoro
- la compilation a aussi une incidence sur la sensibilité des cas: les lettres majuscules doivent-elles être considérées comme semblables aux petites lettres?
la meilleure compilation par défaut pour une base de données globale (par exemple un site web) est probablement Latin1_General_CI_AS. Plus important que la collation est de s'assurer que toutes les colonnes textuelles utilisent le nvarchar type de données.
aussi longtemps que vous utilisez les colonnes NVARCHAR (comme vous le devriez pour les données internationales mélangées), toutes les collations *_bin et *_BIN2 effectuent la même comparaison/tri binaire basé sur les points de code Unicode. Il n'est pas question que l'un de vous choisir. Latin1_General_BIN2 ressemble à un choix Générique raisonnable.
Source:http://msdn.microsoft.com/en-us/library/ms143350 (v=sql.105).aspx