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