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

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

1
PostgreSQLでテーブルの照合を決定する方法は?
PostgreSQLのテーブルで使用されている照合のチェックをスクリプト化したいのですが、グーグル検索Postgresql detect collationがうまく機能しておらず、ドキュメントでは簡単に検索できません。 誰が私にこれを確認する方法を教えてもらえますか?

1
「どこ」でアクセントを無視する
データベースには、caron / hatschekを使用した複数のエントリがあります。現在、ユーザーは、なしでエントリを検索するときに、caron / hatschekを含むエントリを検索したいと考えています。これを簡単な例で示します。 データベースにエントリがあります(名前の連絡先) Millière この名前はその人が住んでいる国で正しいです 私たちの国では、caron / hatschekの文字はないため、ユーザーはを検索しMilliereます。è明らかに一致しないため、結果は表示されませんe。 私は、これはとして実現することができるか見当がつかないé、è、êその多くは、より利用可能です(これは手紙のための唯一の例ですe...)。 (文字列をすべてcaron / hatschekで基本文字列に置き換えるだけでよいので、他の方法ははるかに簡単です。明らかに、ユーザーは、障害のある名前ではなく、データベースの名前の正しいバージョンを望んでいます。)


2
データベースのデフォルトの照合順序を変更したときのLatin1_General_BINのパフォーマンスへの影響
データベース照合をに設定して、Latin1_General_BIN文字列比較で大文字と小文字を区別します。これはパフォーマンスに影響しますか?データベースのDMLまたはDDL操作に影響はありますか?データベースは既にテーブルとともに存在しています。

4
SQL Server 2005/2008 UTF-8照合/文字セット
私はセットに直接オプション(複数可)を見つけることができませんUTF-8rellated Collations/Charsetsと同じで、他のSQLエンジンに設定することも可能ですが、SQL Serverの2005/2008はそこだけでラテン語とSQL照合順序は、SQL Serverの2005/2008に。 これらの照合/文字セットをSQL Serverエンジン(両方のバージョン)2005/2008 Win2008 OSで強制/インストールするオプションはありますか

2
なぜ数字以外が「0-9」なのですか?
私のサーバーのデフォルトの照合は、次のクエリによって決定されるLatin1_General_CI_ASです。 SELECT SERVERPROPERTY('Collation') AS Collation; この照合により、述語を使用して文字列内の数字以外の文字と一致できることを発見して驚きましたLIKE '[0-9]'。 デフォルトの照合でこれが起こるのはなぜですか?これが役立つケースは考えられません。バイナリ照合を使用して動作を回避できることはわかっていますが、デフォルトの照合を実装する奇妙な方法のようです。 数字をフィルタリングすると、数字以外の文字が生成されます すべての可能なシングルバイト文字値を含む列を作成し、数字一致述語で値をフィルタリングすることにより、動作を実証できます。 次のステートメントは、現在のコードページの各コードポイントに1つずつ、256行の一時テーブルを作成します。 WITH P0(_) AS (SELECT 0 UNION ALL SELECT 0), P1(_) AS (SELECT 0 FROM P0 AS L CROSS JOIN P0 AS R), P2(_) AS (SELECT 0 FROM P1 AS L CROSS JOIN P1 AS R), P3(_) AS (SELECT 0 …

4
次の文字列を次の順序で並べ替える照合順序はありますか?1,2,3,6,10,10A、10B、11?
可変長の整数を含むVARCHAR列を持つデータベースがあります。私はそれらをソートして、10が1ではなく9の後に来るようにし、70Aが70の後に来るようにします。WHERE句のPATINDEX()、CTE、およびCASEステートメントでこれを行うことができました。 しかし、これが不必要な照合があるかどうか疑問に思っていました。

2
character_set_clientの値をutf8mb4に設定します
私のDBをこのガイドにutf8mb4従うように変換しようとしています。私は設定しました: [client] default-character-set=utf8mb4 [mysql] default-character-set=utf8mb4 [mysqld] init-connect='SET NAMES utf8mb4' collation_server=utf8mb4_unicode_ci character_set_server=utf8mb4 skip-character-set-client-handshake しかし、の値character_set_clientとcharacter_set_results、まだはutf8mb4に変更されません。 mysql> SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%'; +--------------------------+--------------------+ | Variable_name | Value | +--------------------------+--------------------+ | character_set_client | utf8 | | character_set_connection | utf8mb4 | | character_set_database | utf8mb4 | | character_set_filesystem | binary …
12 mysql  collation  utf-8 

1
N'Șc 'は、Latin1_General_CI_AS照合を使用してN'C'の重複キーを検討しました
NVARCHAR(50)列を含む一意のキーを持つテーブルがあります(正しいかどうかはわかりますが、あります)。そのため、挿入しようとすると、ȘcまたはC(挿入の順序は関係ありません)、照合の問題により2番目の挿入で中断します。ここにエラーがあります: (1行が影響を受けました)メッセージ2601、レベル14、状態1、行16一意のインデックス 'IX_TestT'を持つオブジェクト 'dbo.testT'に重複するキー行を挿入できません。重複するキーの値は(C)です。 返品を選択: データベースのデフォルトの照合はLatin1_General_CI_ASです。既存の構造をあまり変更せずに、その解決方法をしばらく探しましたが、機能する方法を見つけることができませんでした。さまざまな照合順序と組み合わせを試しましたが、すべて失敗します。まだ展開されていないキャラクターの展開などについて(こことここ)を読んでください。これは、問題を再現するために使用しているサンプルコードです。自由に変更し、これを解決するのに役立つと思われるものをお勧めします。 CREATE TABLE testT ( [Default_Collation] [NVARCHAR] (50) COLLATE DATABASE_DEFAULT, [Latin1_General_CI_AS] [NVARCHAR] (50) COLLATE Latin1_General_CI_AS, [Latin1_General_CI_AI] [NVARCHAR] (50) COLLATE Latin1_General_CI_AI, [SQL_Collation] [NVARCHAR] (50) COLLATE SQL_Latin1_General_CP1_CI_AS); CREATE UNIQUE CLUSTERED INDEX [IX_TestT] ON [dbo].[testT] ([Default_Collation]) ON [PRIMARY] GO INSERT INTO testT SELECT N'Șc', --COLLATE Latin1_General_CI_AS N'Șc', --COLLATE …

4
単一のデータベースで列の照合順序を混在させるのが悪いと考えられるのはなぜですか?
私にこの質問をするように促す2つの理由があります。 tSQLt T-SQLテストフレームワークtSQLtは、デフォルト以外の照合を持つ列が存在する場合、それを「高重大度」の問題と見なします。テストの作成者は次のように述べています。 すべての文字列列に、データベースのデフォルトの照合と一致する照合が必要であることを示唆していません。代わりに、それが異なる場合には、それには十分な理由があるはずだと提案しています。 しかし、前述のように、失敗したテストの重大度は高いと見なされます。 Octopus Deploy Octopus Deploy Serverの構成中に、OctopusServer-instanceの初期化中に、セットアップがFATALエラーで失敗します。記事これは単純な要件ですが、理由を説明しないエラーメッセージに関連するが、それはからとタコのバージョン3.8を含め、今後の展開のための要件となることを述べています。 補足として、RedGateのCIツールパッケージであるDLM Automation Suiteは、さまざまな照合を使用したデプロイメントを問題なくサポートします。 すべての列の照合順序をデータベースのデフォルトに保つという推奨は、私にとってはガイドラインまたはベストプラクティスに似ています。一部の人がなぜこのような重大なエラーと見なしているのですか?

3
大文字と小文字を区別するデータベースで大文字と小文字を区別しないLIKEを行う方法
私のベンダーでは、データウェアハウスデータベースで大文字と小文字を区別する必要がありますが、それに対して大文字と小文字を区別しないクエリを実行する必要があります。 大文字と小文字を区別するデータベースで、大文字と小文字を区別しないようにこれをどのように記述しますか? Where Name like '%hospitalist%'

3
特定のアラビア文字を同一として扱う
アラビア語には、ا(alef)やأ(hamza付きのalef)などの文字があります。 ユーザーはそれらを交換可能に書き込み、それらを交換可能に検索したいと考えています。SQL Serverはそれらを個別の文字として扱います。SQLでそれらを同じ文字として扱うにはどうすればよいですか? 挿入時にأ(hamzaを含むアレフ)をا(alef)に置き換えると考えましたが、アラビア語にはا(alef)やأ(hamefを含むアレフ)以外にも多くの選択肢があります。 私が試したArabic_CI_ASし、Arabic_CI_AIそれは問題を解決していません。 問題を再生成するスクリプトは次のとおりです。 CREATE TABLE [dbo].[TestTable] ( [ArabicChars] [nvarchar](50) NOT NULL, CONSTRAINT [PK_TestTable] PRIMARY KEY CLUSTERED ( [ArabicChars] ASC ) ) ON [PRIMARY]; INSERT INTO TestTable values (N'احمد'); INSERT INTO TestTable values (N'أحمد'); SELECT * FROM TestTable WHERE ArabicChars like N'ا%'; 結果は次のとおりです。 ArabicChars احمد (1 row(s) affected) …

1
ORDER BYと文字と数字の混合文字列の比較
通常は「自然に」ソートする必要がある数字と文字の混合ストリングである値について、いくつかのレポートを作成する必要があります。たとえば、「P7B18」や「P12B3」など。@文字列は主に文字と数字が交互になったシーケンスです。ただし、これらのセグメントの数とそれぞれの長さは異なる場合があります。 これらの数値部分を数値順にソートしてください。明らかに、これらの文字列値をで直接処理する場合ORDER BY、「P12B3」は「P7B18」の前に来るでしょう。 「P12」。 範囲の比較などもできるようにしたいと思い@bin < 'P13S6'ます。浮動小数点数や負の数を処理する必要はありません。これらは厳密に私たちが扱っている負でない整数になります。文字列の長さとセグメント数は、上限が固定されていないため、潜在的に任意である可能性があります。 私たちのケースでは、文字列の大文字小文字の区別は重要ではありませんが、照合に対応した方法でこれを行う方法がある場合、他の人が便利だと思うかもしれません。これらすべての最も醜い部分は、WHERE句で順序付けと範囲フィルタリングの両方を実行できるようにしたいです。 これをC#で実行している場合、それは非常に単純なタスクです。いくつかの解析を行ってアルファを数値から分離し、IComparableを実装すれば、基本的にはこれで完了です。もちろん、SQL Serverは、少なくとも私の知る限り、同様の機能を提供していないようです。 誰かがこれを機能させるための良いトリックを知っていますか?IComparableを実装し、これを期待どおりに動作させるカスタムCLR型を作成する、あまり公表されていない機能はありますか?私はまた、愚かなXMLトリック(「リストの連結」も参照)に反対していません。また、サーバーでCLR正規表現のマッチング/抽出/置換ラッパー関数も使用できます。 編集: もう少し詳細な例として、データがこのような動作をするようにしたいと思います。 SELECT bin FROM bins ORDER BY bin bin -------------------- M7R16L P8RF6JJ P16B5 PR7S19 PR7S19L S2F3 S12F0 つまり、文字列をすべての文字またはすべての数字のトークンに分割し、アルファベット順または数値順に並べ替えます。左端のトークンが最も重要な並べ替え条件です。先ほど触れたように、IComparableを実装した場合の.NETの簡単な説明ですが、SQL Serverでそのようなことを行う方法(またはその方法)がわかりません。それは確かに私がこれまでに10年ほどの作業で遭遇したものではありません。

3
作成時にデータベース照合を変更するトリガー
トリガーを作成して、作成時にデータベースの照合を変更しようとしていますが、トリガー内で使用するデータベース名をキャッチするにはどうすればよいですか? USE master GO CREATE TRIGGER trg_DDL_ChangeCOllationDatabase ON ALL SERVER FOR CREATE_DATABASE AS declare @databasename varchar(200) set @databasename =db_name() ALTER DATABASE @databasename COLLATE xxxxxxxxxxxxxxxxxxx GO 明らかに、これは機能していません。

2
Unicodeを非Unicodeに変換するときの自動変換/ NVARCHARからVARCHAR
Unicodeコードポイント9619は「ダークシェード」と呼ばれる文字です:▓(http://unicode-table.com/en/search/?q=9619)。 SQL_Latin1_General_CP1_CI_AS照合と1252コードページを使用すると?、コードページ1252にこの文字が含まれていないように見え、これがSQL Serverのように見えるため、そのUnicode文字を非Unicodeデータ型にキャスト/変換すると疑問符()が発生することが予想されます。変換できない場合の動作。 したがって、私の質問は、SQL Serverがこの文字を「パイプ、壊れた垂直バー」であるASCIIコード166に変換するのはなぜ¦ですか。 SELECT NCHAR(9619), CAST(NCHAR(9619) AS CHAR(1)), ASCII(CAST(NCHAR(9619) AS CHAR(1)))
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.