タグ付けされた質問 「collation」

照合は、文字セット内の文字を比較するためにデータを並べ替えて比較する方法を決定する一連のルールです。

4
SQL Server照合順序を変更する方法
サーバー全体と特定のデータベースのSQL Server 2008 R2 Express Default Collat​​ionを変更するにはどうすればよいですか？ SQL Server Management Studioのビジュアルインターフェイスを使用してそれを行う方法はありますか？[サーバーのプロパティ]ウィンドウ（および対応する[データベースのプロパティ]ウィンドウ）では、このプロパティは編集できません。
1
PostgreSQL ORDER BYで大文字と小文字が区別されないのはなぜですか？
DebianでPostgres 9.4.4を実行していますが、次のようORDER BYな動作になります。 veure_test=# show LC_COLLATE; lc_collate ------------- en_US.UTF-8 (1 row) veure_test=# SELECT regexp_split_to_table('D d a A c b CD Capacitor', ' ') ORDER BY 1; regexp_split_to_table ----------------------- a A b c Capacitor CD d D (8 rows) そしてuname -a： Linux ---- 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux しかし、Postgres …
3
多言語のWebサイトではどの照合を選択する必要がありますか？
照合はクエリ速度に影響を与えますか？照合順序によってテーブルのサイズは変わりますか？ 推奨される照合となる可能性のあるすべての言語（たとえば、Googleの場合）をサポートする必要があるWebサイトを構築する場合はどうすればよいですか？ などの文字を保存する必要があり日本語ます。ウェブサイトでの検索somethingではsóméthíng入力のために戻る必要があり、大文字と小文字を区別しない必要があります。 どれが最良の選択であるかをどのようにして知ることができますか？このケースに適した照合はどれですか？
2
PostgreSQLデータベースに対するLC_CTYPEの影響は何ですか？
そのため、PostgreSQLを搭載したDebianサーバーはほとんどありません。歴史的に、これらのサーバーとPostgreSQLはLatin 9文字セットでローカライズされていましたが、当時は問題ありませんでした。現在、ポーランド語、ギリシャ語、中国語などを処理する必要があるため、それを変更することは大きな問題になります。 UTF8データベースを作成しようとすると、次のメッセージが表示されました。 エラー：UTF8のエンコードはロケールfr_FRに一致しません詳細：選択したLC_CTYPE設定にはLATIN9のエンコードが必要です。 私は昔のパルグーグルでいくつかのテーマについて調査しましたが、Debianの更新LANG、正しい文字セットでのPostgreSQLの再コンパイル、すべてのLC_システム変数およびその他のあいまいなソリューションの編集など、複雑すぎる手順しか見つかりませんでした。とりあえず、この問題はさておきましょう。 最近、それは再び戻ってきました。ギリシャ人は物を望み、ラテン語9は望んでいません。そして、私がこの問題を再び検討している間に、ある同僚が私のところに来て、「ええ、簡単だ、見て」と言いました。 彼は何も編集せず、手品をしませんでした。彼はこのSQLクエリを作成しました。 CREATE DATABASE my_utf8_db WITH ENCODING='UTF8' OWNER=admin TEMPLATE=template0 LC_COLLATE='C' LC_CTYPE='C' CONNECTION LIMIT=-1 TABLESPACE=pg_default; そして、それはうまくいきました。 私は実際には知りLC_CTYPE='C'ませんでしたが、これがGoogleの最初のソリューションやStack Overflowでも使用されていないことに驚きました。私は周りを見回しましたが、PostgreSQLのドキュメントに言及しているだけです。 LC_CTYPEがCまたはPOSIXの場合、任意の文字セットが許可されますが、LC_CTYPEの他の設定では、正しく機能する文字セットは1つだけです。LC_CTYPE設定はinitdbによって凍結されるため、クラスターの異なるデータベースで異なるエンコードを使用するための明らかな柔軟性は、CまたはPOSIXロケールを選択する場合を除いて、実際よりも理論的です（したがって、実際のロケール認識を無効にします）。 だから、これはあまりにも簡単で完璧すぎると思いました。マイナス面は何ですか？そして、私はまだ答えを見つけるのに苦労しています。だからここに投稿します： tl; dr：特定のローカライズで使用LC_CTYPE='C'することのマイナス面は何ですか？そうするのは悪いですか？私は何を壊すことを期待すべきですか？
1
SQL Server Unicode / NVARCHAR文字列を絵文字または補助文字に設定するにはどうすればよいですか？
Unicodeコードポイントに基づいて特定の文字にUnicode文字列変数を設定します。 65535を超えるコードポイントを使用したいのですが、SQL Server 2008 R2データベースにはの照合順序がありSQL_Latin1_General_CP1_CI_ASます。 MicrosoftのNCHARドキュメントによると、NCHAR関数は次のように整数を取ります。 integer_expression データベースの照合に補助文字（SC）フラグが含まれていない場合、これは0〜65535（0〜0xFFFF）の正の整数です。この範囲外の値を指定すると、NULLが返されます。補助文字の詳細については、照合とUnicodeサポートを参照してください。 データベースの照合が補助文字（SC）フラグをサポートしている場合、これは0〜1114111（0〜0x10FFFF）の正の整数です。この範囲外の値を指定すると、NULLが返されます。 したがって、このコード： SELECT NCHAR(128512); NULLこのデータベースに戻ります。 これと同じものを返したい： SELECT N'😀'; 照合に「補助文字（SC）フラグが含まれていない」データベースで、コードを使用して（実際の絵文字を使用せずに）Unicode文字列変数（nvarcharなど）を絵文字に設定するにはどうすればよいですか？ 絵文字Unicodeコードポイントの全リスト （最終的には、すべてのキャラクターが機能するようにします。参照しやすいように絵文字を選択しました。） （サーバーはSQL Server 2008 R2ですが、それ以降のバージョンのソリューションについても興味があります。） 方法がないと仮定して、適切な照合を備えた別のデータベースのインラインユーザー定義関数を参照できますか？ 「補足文字」フラグを持つ照合を見つけるにはどうすればよいですか？ これにより、サーバー上のレコードは返されません。 SELECT * FROM sys.fn_helpcollations() WHERE name LIKE 'SQL%[_]SC'; 動作するSQL Server 2012が導入されLatin1_General_100_CI_AS_SCたようです。古いインスタンスに照合をインストールできますか？ 照合参照： SQL Serverのchar、nchar、varchar、nvarcharの違いは何ですか？ マイクロソフトの補助文字照合情報 MicrosoftのSQL Server 2008 R2照合リスト 照合に関係なく、SQL Serverが拡張文字を理解して処理できる理由についての説明はありNCHARますか？
3
国際データベースの照合を選択する方法は？
さまざまな言語（UTF-8を使用）でデータを格納するデータベースを設計しているので、クエリの結果を表示する最良の方法は、クエリ自体の実行中にユーザーの言語に従って並べることです（複数あるためそれを行う正しい方法）、次のように： SELECT a < b COLLATE "de_DE" FROM test1; これが国際データを処理する正しい方法であると仮定すると、データベース自体にとって最適な照合はどれですか？PostgreSQLのドキュメントによると： C照合とPOSIX照合はどちらも「従来のC」動作を指定します。この動作では、ASCII文字「A」から「Z」のみが文字として扱われ、ソートは文字コードバイト値によって厳密に行われます。 この場合、これが最良の選択だと思いますか、それとも間違っていますか？ （ボーナス質問：クエリ自体で照合順序を選択するには遅すぎますか？）。
4
sys.databasesのいくつかの列の照合はどうなっていますか？
2005年から2012年までのさまざまなバージョンのSQL ServerにUNPIVOT含まれるさまざまな列でを実行しようとしていますsys.databases。 UNPIVOT次のエラーメッセージで失敗しています。 メッセージ8167、レベル16、状態1、行48 列「CompatibilityLevel」のタイプは、UNPIVOTリストで指定された他の列のタイプと競合します。 T-SQL： DECLARE @dbname SYSNAME; SET @dbname = DB_NAME(); SELECT [Database] = unpvt.DatabaseName , [Configuration Item] = unpvt.OptionName , [Configuration Value] = unpvt.OptionValue FROM ( SELECT DatabaseName = name , RecoveryModel = CONVERT(VARCHAR(50), d.recovery_model_desc) , CompatibilityLevel = CONVERT(VARCHAR(50), CASE d.[compatibility_level] WHEN 70 THEN 'SQL Server 7' …
2
アクセントセンシティブソート
なぜこれらの2つのSELECTステートメントが異なるソート順になるのですか？ USE tempdb; CREATE TABLE dbo.OddSort ( id INT IDENTITY(1,1) PRIMARY KEY , col1 NVARCHAR(2) , col2 NVARCHAR(2) ); GO INSERT dbo.OddSort (col1, col2) VALUES (N'e', N'eA') , (N'é', N'éB') , (N'ë', N'ëC') , (N'è', N'èD') , (N'ê', N'êE') , (N'ē', N'ēF'); GO SELECT * FROM dbo.OddSort ORDER BY col1 …
2
大文字と小文字を区別しない照合はどのように機能しますか？
SQL Serverの既定の照合タイプでは、大文字と小文字を区別しない文字列に対してインデックスを作成できますが、データの大文字と小文字は保持されます。これは実際にどのように機能しますか？実際のナットとボルト、ビットとバイト、または詳細を説明する優れたリソースを探しています。 create table casetest (fruitnames nvarchar(50) not null); create unique index IX_fruitnames on casetest(fruitnames); insert into casetest values ('apples'); insert into casetest values ('Pears'); -- this insert fails insert into casetest values ('pears'); -- this yields 'Pears' as a result select * from casetest (forceseek) where fruitnames = 'PEARS' …
2
テーブル行の「CO2」を「CO₂」に更新できません
この表が与えられた場合： CREATE TABLE test ( id INT NOT NULL, description NVARCHAR(100) COLLATE Modern_Spanish_CI_AS NOT NULL ); INSERT INTO test (id, description) VALUES (1, 'CO2'); 活版印刷の問題を解決できないことに気付きました。 SELECT * FROM test WHERE id = 1; UPDATE test SET description = 'CO₂' WHERE id = 1; SELECT * FROM test WHERE id = …
2
DBMSには、大文字と小文字を区別せず、アクセントを区別しない照合順序がありますか？
この質問はベンダー/バージョンに依存しないことに注意してください 英語を話す人（タイピスト、作家）としては、単語の大文字と小文字の区別は正しいが、正しいアクセントが必ずしも正しい方向に進むとは限らないように思えます。 シャンゼリゼ通りにあるレストランクロエのテテアテテで熟考しました。 あなたはそれでアイデアを得る。 そのため、今日、大文字と小文字を区別し、アクセントを区別しない照合を使用する検索条件が必要であると考えましたが、見つかりませんでした。これには正当な理由がありますか、それとも私にとってはまれなユースケースですか？ ここに私が見ていたいくつかのドキュメントの例があります（ただし、ベンダー/バージョンに依存しないと考えています）。 SQL Server照合名（SQL Server 2008 R2）
1
テキスト列でtext_pattern_opsにインデックスを付けるのはなぜですか？
今日、Seven WeeksのSeven Databasesでは、オペレーターごとのインデックスを紹介しました。 text_pattern_ops値が小文字でイ​​ンデックス付けされている限り、演算子クラスインデックスを作成することにより、以前のクエリに一致するパターンの文字列にインデックスを付けることができます。 CREATE INDEX moves_title_pattern ON movies ( (lower(title) text_pattern_ops); text_pattern_opsタイトルがテキストタイプであるため、これを使用しました。あなたは、インデックスのvarchar、文字、または名前に必要な場合は、関連するオペレーションを使用しますvarchar_pattern_ops、bpchar_pattern_opsとname_pattern_ops。 この例は本当に紛らわしいと思います。なぜこれが便利なのですか？ 列がテキストタイプの場合、他のタイプ（varchar、char、name）は検索値として使用される前にテキストにキャストされませんか？ そのインデックスは、デフォルト演算子を使用したインデックスとどのように動作しますか？ CREATE INDEX moves_title_pattern ON movies (lower(title));
2
SQL 2005 [SQL_Latin1_General_CP1_CI_AS]から2008への移行-「後方互換性」を使用して機能を失う
SQL 2005 [インスタンスとDBの照合順序SQL_Latin1_General_CP1_CI_AS]からSQL 2008 [デフォルトは]に移行していますLatin1_General_CI_AS。 SQL 2008 R2のインストールを完了し、デフォルトのLatin1_General_CI_AS照合を使用しましたが、データベースの復元はまだSQL_Latin1_General_CP1_CI_ASです。例外的な問題が発生しました- Latin1_General_CI_ASデータベースが存在していた ときの#tempテーブル SQL_Latin1_General_CP1_CI_ASと、これが現在の場所です-落とし穴についてのアドバイスが必要です。 SQL 2008 R2のインストールでは'SQL Collation, used for backwards compatibility'、2005データベースと同じ照合を選択するオプションがある場所で使用するインストールオプションがありますSQL_Latin1_General_CP1_CI_AS。 これにより、＃tempテーブルで問題が発生することはなくなりますが、落とし穴はありますか？ SQL 2008の「現在の」照合を使用しないことにより、あらゆる種類の機能または機能が失われますか？ 2008年からSQL 2012に移行したとき（2年以内など）はどうですか？問題はありますか？ ある時点で行くことを余儀なくされLatin1_General_CI_ASますか？ 一部のDBAのスクリプトが完全なデータベースの行を完了し、新しい照合を使用してデータベースに挿入スクリプトを実行することを読みました。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.