回答編集履歴
1
記述が分かりにくかったので修正
test
CHANGED
|
@@ -3,6 +3,8 @@
|
|
|
3
3
|
|
|
4
4
|
|
|
5
5
|
既存のテーブル構造の変更が許されるのであれば、
|
|
6
|
+
|
|
7
|
+
CSVでデータを投入するのではなく、ユーザ毎にレコードを分ける形で
|
|
6
8
|
|
|
7
9
|
|
|
8
10
|
|
|
@@ -12,10 +14,14 @@
|
|
|
12
14
|
|
|
13
15
|
ロググループID（複数のユーザに対して一括処理したタイミングで同じIDが作られる）
|
|
14
16
|
|
|
15
|
-
ユーザーコード（インデックスを張る）
|
|
17
|
+
ユーザーコード（１ユーザ１レコードにする、インデックスを張る）
|
|
16
18
|
|
|
17
19
|
|
|
18
20
|
|
|
19
21
|
というテーブルにして、ユーザーコードを完全一致で検索すればかなり早くなると思うのですが、
|
|
20
22
|
|
|
21
23
|
こういったアプローチは要件的に難しそうですか？
|
|
24
|
+
|
|
25
|
+
*一括処理時のユーザ数によってはレコード数が爆発的に増える可能性があるので、実際の条件で計算してみないとわからないとは思います。
|
|
26
|
+
|
|
27
|
+
*データ投入時のコストは確実に増えるので、そのあたりのトレードオフが認められるかというのもあります。
|