0

MySQL 5.6.10 の親子テーブルのペアに問題があります。Django アプリは、SAS からの .tab データ ファイルだけでなく、ダウンストリームにも関与しています。

親テーブル (ccs1) は 18 の高レベルの医療コードを定義しており、これを idx とラベル付けしており、1 から 18 までの番号に varchar(2) フィールドを使用しています。親レベルのコード: 1.1、1.2、2.1、2.2、2.3 など。また、独自のテーブル内で idx というラベルが付けられています。子内で、子の idx コードの最初の番号である ccs1_id という名前の追加変数を作成し、varchar(2)それを親テーブルの同等の idx 変数への外部キー参照として設定しようとしています。(これは、好奇心旺盛な人のために業界標準の CCS テーブルを使用しています。4.4.5.1 など、合計で 4 つのレベルがあります。そうでなければ、varchar 表現を維持できません)。

子テーブルの読み取り時に、foreign_key_checks = 0 でのデータ挿入が失敗します。キー チェックをオフにすると、データが正しく読み取られているように見えます (MySQL ワークベンチ GUI 内で表示した場合)。django アプリケーションでデータを使用し、親の外部キー参照を介して子テーブルの値をフィルター処理しようとすると、 2桁 (文字)の高レベル コードのみが正常にフィルター処理されます: 10. 18. 親レベルのフィルター処理キー 1 ~ 9 は失敗します。

両方のテーブルは、varchar(2) として関連する変数を使用して構築されます。以下に、それぞれの SHOW CREATE TABLE 出力を含めました。

これまでのところ、親と子のテーブルをロードしようとしたときの SHOW ENGINE ログからの最新の外部キー エラー、foreign_key_checks = 1 からの私の最良の手がかりです。

TRANSACTION 1022234, ACTIVE 0 sec inserting, thread declared inside InnoDB 5000
mysql tables in use 1, locked 1
4 lock struct(s), heap size 320, 1 row lock(s), undo log entries 1
MySQL thread id 177, OS thread handle 0x2280, query id 12426 localhost 127.0.0.1 root        
System lock
LOAD DATA LOCAL INFILE '/abc/dim_dx_ccs2.tab'
INTO TABLE dim_dx_ccs2
IGNORE 1 LINES
(idx, idxm, label, ccs1_id)
Foreign key constraint fails for table `phrat`.`dim_dx_ccs2`:
,
CONSTRAINT `ccs1_id_refs_idx_1213764e` FOREIGN KEY (`ccs1_id`) REFERENCES `dim_dx_ccs1`    (`idx`)
Trying to add in child table, in index `ccs1_id_refs_idx_1213764e` tuple:
DATA TUPLE: 2 fields;
0: len 2; hex 310d; asc 1 ;;
1: len 4; hex 80000103; asc     ;;

But in parent table `phrat`.`dim_dx_ccs1`, in index `idx`,
the closest match we can find is record:
PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 1; hex 31; asc 1;;
1: len 4; hex 80000052; asc    R;;

この場合、親テーブルで値「1」を検索する必要があります。最後の 9 行を見ると、MySQL の varchar データ型は、トリミング後に親テーブルの idx 値を長さ 1 として処理し、トリミング前の長さ 2 の値と比較しているように見えますか? つまり、310d(10 進数: 12557) と 31(10 進数: 49) の指定された 16 進数値は、1 から 18 の間のみである必要がある、読み取っているデータを考えると意味がありません。 1: フィールドは適切に見えます。これらは各テーブルの主キー (ID) であり、最初のエントリ (外部キー値の場合は "1" または "1 ") になります。

ここでもっと基本的なことが欠けているのでしょうか、それともこれが問題の根源ですか? もしそうなら、どうすれば解決できますか?長さを設定した CHAR 値に切り替えることができ、解決する可能性があると思いますが、ここで何が起こっているのかを理解したいと思います。

参考までに、SHOW CREATE TABLE の出力を次に示します。

-------------------------------------------------------------------------------------+
 dim_dx_ccs1 | CREATE TABLE `dim_dx_ccs1` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `idx` varchar(2) COLLATE utf8_unicode_ci NOT NULL,
 `idxm` varchar(2) COLLATE utf8_unicode_ci NOT NULL,
 `label` varchar(64) COLLATE utf8_unicode_ci NOT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `idx` (`idx`),
 UNIQUE KEY `idxm` (`idxm`)
 ENGINE=InnoDB AUTO_INCREMENT=65 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci |
-------------+--------------------------------------------------------------------------------------


 dim_dx_ccs2 | CREATE TABLE `dim_dx_ccs2` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `idx` varchar(5) COLLATE utf8_unicode_ci NOT NULL,
 `idxm` varchar(5) COLLATE utf8_unicode_ci NOT NULL,
 `label` varchar(128) COLLATE utf8_unicode_ci NOT NULL,
 `ccs1_id` varchar(2) COLLATE utf8_unicode_ci NOT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `idx` (`idx`),
 UNIQUE KEY `idxm` (`idxm`),
 KEY `ccs1_id_refs_idx_1213764e` (`ccs1_id`),
 CONSTRAINT `ccs1_id_refs_idx_1213764e` FOREIGN KEY (`ccs1_id`) REFERENCES `dim_dx_ccs1` (`idx`)
 ENGINE=InnoDB AUTO_INCREMENT=259 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci |
-------------+----------------------------------------------------------------------------------------

追加の詳細:

  • データ テーブルは Unix サーバー (SAS が存在する場所) から生成されますが、.tab ファイルとして Windows 環境にエクスポートされます。
4

1 に答える 1

1

詳細を見ると、tabファイルには CR/LF が含まれているように見えますが、インポートでは LF のみが想定されます。

これにより、予期される 0x31 ('1') インポートが 0x31 0x0d ('1\r') として作成されます。これはプライマリ テーブルの値と一致しないため、インポートは失敗します。

于 2013-05-11T18:42:09.077 に答える