0

最近、文字列に関する奇妙な問題に遭遇しました。

私は2つのテーブルを持っていました:

| AgentCodes | CREATE TABLE `AgentCodes` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `AgentName` varchar(32) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `AgentName` (`AgentName`),
) ENGINE=ndbcluster AUTO_INCREMENT=319 DEFAULT CHARSET=latin1 |

と

| AgentNumbers | CREATE TABLE `AgentNumbers` (
  `AgentName` varchar(32) NOT NULL,
  `TelephoneNumber` varchar(64) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `AgentName` (`AgentName`),
  KEY `TelephoneNumber` (`TelephoneNumber`),
) ENGINE=ndbcluster AUTO_INCREMENT=62 DEFAULT CHARSET=latin1 |

LIKEAgentCodes.AgentName テーブルでは機能しませんでした。AgentName にunicodecharset があるためだと推測したため、そのフィールドの charset を に変更しましたLatin1。

問題は、AgentNumbers テーブルが AsteriskPBX キューのリアルタイム テーブルとして使用されていることです。基本的には、エージェントの名前を取得し、発信者をそのキューに入れます。

たとえば、JohnDoe という名前を取得すると、conf ファイルは次のようになります。

[JohnDoe]
musicclass = temp
timeout = 35
member => SIP/...

no such queueというエラーが表示されます。問題が何であるかを知っていたので、名前をデータベースからそのconfファイルにコピーしたところ、機能しました。

私の質問は、その問題を引き起こす可能性があるものです.2つの文字列をファイルとデータベースに表示し、それらを3番目のファイルにコピー/貼り付けます(それらはまだ同一に見えます)。それらは同じであると認識されませんか?

エンコーディング/文字セットと関係があると思いますが、理由を聞きたいです:)

4

1 に答える 1

2

MySQL LIKE は、文字列比較ではなく文字単位の比較を行うことを忘れないでください。したがって、末尾のスペースなどは重要です。また、実際の SQL はありません。たとえば、比較対象のリテラルまたは変数です。

また、AgentName が 2 つの異なるテーブルにあるのはなぜですか? これは正規化されていないように見えます。もちろん、なぜ正規化が重要なのかがわかります。

于 2013-06-10T06:46:29.660 に答える