回答編集履歴

5

修正

2018/04/06 01:32

投稿

sazi
sazi

スコア25195

test CHANGED
@@ -36,7 +36,7 @@
36
36
 
37
37
 
38
38
 
39
- 因みに考えられるエラー(チェックすべき項目)としては以下が考えられます。
39
+ 因みにエラー(チェックすべき項目)としては以下が考えられます。
40
40
 
41
41
  ・一意制約違反
42
42
 

4

追記

2018/04/06 01:32

投稿

sazi
sazi

スコア25195

test CHANGED
@@ -32,4 +32,20 @@
32
32
 
33
33
  私が良く行うのは、エラーになりようがないテーブル(キーや制約の無い全てtext属性)を用意して取り込み、そこでエラーチェックなり加工するなりを行って、本来のテーブルへ登録するようにしています。
34
34
 
35
- SQLのみで行えることや、大量データの場合CSVに対してよりも高速というのが利点です。
35
+ SQLのみで行えることや、大量データの場合CSVに対してよりも高速、他のデータの整合性チェック可、というのが利点です。
36
+
37
+
38
+
39
+ 因みに考えられるエラー(チェックすべき項目)としては以下が考えられます。
40
+
41
+ ・一意制約違反
42
+
43
+ ・NotNull制約違反
44
+
45
+ ・属性エラー(数値項目に文字)
46
+
47
+ ・桁あふれ(文字なら桁数、数値ならオーバーフロー)
48
+
49
+ ・エスケープ文字使用(区切り記号と同じ記号を文字列中で使用)
50
+
51
+ ※最後のエスケープ文字使用についてはチェック状況に応じた臨機応変さが必要なことが多い。

3

修正

2018/04/06 01:22

投稿

sazi
sazi

スコア25195

test CHANGED
@@ -30,6 +30,6 @@
30
30
 
31
31
 
32
32
 
33
- 私が良く行うのは、エラーになりようがないテーブル(キーや制約の無い全てtext属性)を用意して取り込み、そこでエラーチェックなり加工するなりを行って、本来のテーブルへ登録するようにしています。
33
+ 私が良く行うのは、エラーになりようがないテーブル(キーや制約の無い全てtext属性)を用意して取り込み、そこでエラーチェックなり加工するなりを行って、本来のテーブルへ登録するようにしています。
34
34
 
35
35
  SQLのみで行えることや、大量データの場合CSVに対してよりも高速というのが利点です。

2

追記

2018/04/06 01:10

投稿

sazi
sazi

スコア25195

test CHANGED
@@ -22,7 +22,7 @@
22
22
 
23
23
 
24
24
 
25
- 何度も行うのが効率悪いという事ですが、多分CSVの編集に苦労されているのではないでしょうか。
25
+ 何度も行うのが効率悪いという事ですが、1000件程度でしたらSQL*Loaderの処理にそんなに時間は掛からないので、多分CSVの編集に苦労されているのではないでしょうか。
26
26
 
27
27
  テキストエディタは論外なので、もしエクセルでやられているとかでしたら、CSV専用のエディタを使われてはどうでしょう。
28
28
 

1

追記

2018/04/06 01:09

投稿

sazi
sazi

スコア25195

test CHANGED
@@ -5,3 +5,31 @@
5
5
  OPTIONS (ERRORS=-1)
6
6
 
7
7
  ```
8
+
9
+ 追記
10
+
11
+ ---
12
+
13
+ > 「同一レコードの複数のカラムにそれぞれエラーがあった場合でも、一回の処理で全て検出する」
14
+
15
+
16
+
17
+ SQL*Loaderは高速にデータを取り込むのを目的とした処理ですから、一つでもエラー検知したら行をSKIPするのは、当然の仕様だと思います。
18
+
19
+
20
+
21
+ そうは言っても、エラーチェックも兼用出来たら、というのは理解できます。
22
+
23
+
24
+
25
+ 何度も行うのが効率悪いという事ですが、多分CSVの編集に苦労されているのではないでしょうか。
26
+
27
+ テキストエディタは論外なので、もしエクセルでやられているとかでしたら、CSV専用のエディタを使われてはどうでしょう。
28
+
29
+ [【厳選】Windows用のCSVファイルエディタ【最強のCSVエディタ】](https://matome.naver.jp/odai/2135167399342052801)
30
+
31
+
32
+
33
+ 私が良く行うのは、エラーになりようがないテーブル(キーや制約の無い全全てtext属性)を用意して取り込み、そこでエラーチェックなり加工するなりを行って、本来のテーブルへ登録するようにしています。
34
+
35
+ SQLのみで行えることや、大量データの場合CSVに対してよりも高速というのが利点です。