データベースの設計に詳しい人いる？

VIP

2021.01.15 11:13

1 : 2021/01/15(金) 10:44:45.328 ID:kZJTsYpNp: ユーザーの過去の全ログイン履歴を記録しておく場合って
ログイン履歴テーブル、みたいな１つのテーブルつくって、複数のユーザーで使い回す形になるの？
2 : 2021/01/15(金) 10:45:23.494 ID:1AH04ixI0: 結論は出せないけどいい？
4 : 2021/01/15(金) 10:45:51.293 ID:kZJTsYpNp: >>2
ケースバイケースってこと？
3 : 2021/01/15(金) 10:45:36.277 ID:axSYnnaI0: 複数のユーザーで使い回す？
ってのがなんか逆の構造になってない？
5 : 2021/01/15(金) 10:46:13.368 ID:kZJTsYpNp: >>3
全くの素人なのでどう逆なのかも分からん
6 : 2021/01/15(金) 10:46:43.374 ID:UW/HrYaDM: テーブルって一人のために用意するもんじゃねーが
19 : 2021/01/15(金) 10:49:58.150 ID:kZJTsYpNp: >>6
ユーザーテーブルは
uid, uname
1, 太郎
2, 次郎
みたいなかんじじゃん？
ログイン履歴テーブルは
uid,date
1, 1/3
1, 1/4
2, 1/5
2, 1/6
1, 1/8
みたいな？1人に一つのテーブルって考えではない
22 : 2021/01/15(金) 10:51:12.096 ID:mhD1hqvCM: >>19
それで大丈夫
24 : 2021/01/15(金) 10:52:01.401 ID:CNZkxTAB0: >>19
一人に一つのテーブルではない
ではなく、一人に一つの行ではないでは？
そのテーブル構成で問題ないよ
7 : 2021/01/15(金) 10:46:56.457 ID:FSKJ3OYyp: 逆になんで複数必要なんだ？
8 : 2021/01/15(金) 10:46:59.743 ID:zVZym56p0: ユーザーIDとログイン日時記録するだけじゃ無いの
9 : 2021/01/15(金) 10:47:15.774 ID:Bv8ZN5Zcd: 1テーブルじゃなかったらユーザーごとにテーブル作るってこと？
10 : 2021/01/15(金) 10:47:24.025 ID:kZJTsYpNp: 最終ログイン日時だけって話ならユーザーテーブルに記録すれば良いわけだけど
全履歴ってなると数が不変だからユーザーテーブルに入れるとマズイよね
11 : 2021/01/15(金) 10:47:24.212 ID:ZNa/04+h0: ユーザーテーブルと履歴テーブルが多対多の構造になるね
12 : 2021/01/15(金) 10:47:48.937 ID:8Pl6dGyfd: いいとも
13 : 2021/01/15(金) 10:48:18.156 ID:p2ii67cV0: │連番│ユーザーID│使用端末│タイムスタンプ│
14 : 2021/01/15(金) 10:48:39.236 ID:ZNa/04+h0: 全然多対多じゃねえや
15 : 2021/01/15(金) 10:48:45.098 ID:CNZkxTAB0: ユーザーログイン履歴テーブル作ってカラムは
ユーザーID
ログイン日時
16 : 2021/01/15(金) 10:48:56.081 ID:EEkFEQZT0: SQL文で全員のログインのデータ集めてきてその場で作れば良くね知らんけど
17 : 2021/01/15(金) 10:49:39.030 ID:kQIA+BtGd: ユーザーテーブルには入れないな
ログイン履歴テーブルを新しく1つ作るべき
18 : 2021/01/15(金) 10:49:50.668 ID:IUQ6au170: いったん作ればよくね
20 : 2021/01/15(金) 10:50:57.239 ID:uheAYSi/0: イメージとしてはゴミ箱みたいなのと考えたらいい
家族みんなのレシートを入れていくゴミ箱
つまり「レシートであること」や「いつ入れたか」「誰が入れたか」「KeyのID（自動生成）」これだけでも履歴は成り立つ
21 : 2021/01/15(金) 10:51:09.377 ID:VtA/b8t5r: それ以外なんかあんの？
23 : 2021/01/15(金) 10:51:43.831 ID:UW/HrYaDM: 使用頻度高くねーならログファイルでもいいぞ
28 : 2021/01/15(金) 10:53:20.752 ID:kZJTsYpNp: >>23
なるほど
それもありか
ユーザーがめちゃくちゃ増えてきた時に、ログイン履歴テーブルで管理すると大変だったりするかな
31 : 2021/01/15(金) 10:55:28.874 ID:CNZkxTAB0: >>28
ログインデータは永続保管なの？
37 : 2021/01/15(金) 10:56:51.158 ID:kZJTsYpNp: >>31
一定期間超えた分は削除とかでも良いかな
てか多くのサービスであんまり過去の履歴辿れなくなってるのはこういうことか
39 : 2021/01/15(金) 10:58:11.512 ID:CNZkxTAB0: >>37
ログファイルをaws s3に書き出して一定期間で削除もしくはグレイシアに移行するライフサイクルポリシー設定すれば楽に実装できると思うよ
それならログイン以外のあらゆる処理ログにも対応しやすいし
34 : 2021/01/15(金) 10:56:17.070 ID:lDzz1pt00: >>28
保存期間を設けて月次処理とかで古い履歴は削除とかアーカイブ化して別のテーブルに移動なりしてけば問題ないよ
38 : 2021/01/15(金) 10:57:19.604 ID:mMRuDmuiM: >>28
いいぞ
インデックスつけとけよ
25 : 2021/01/15(金) 10:52:15.890 ID:hcd5gVHua: ログイン以外のアクションも履歴残そうぜ
32 : 2021/01/15(金) 10:55:42.424 ID:kZJTsYpNp: >>25
いろいろ残したいものあるんだよね
たとえば「ニックネーム」の変更履歴とか
26 : 2021/01/15(金) 10:52:17.788 ID:lDzz1pt00: ユーザ情報のテーブルもユーザごとに分けてんの？
27 : 2021/01/15(金) 10:52:46.210 ID:PcoKXuYRd: ユーザーごとにログイン履歴テーブルを用意するって設計はないな
全ユーザーが使用するログイン履歴テーブルを1つ用意する方が普通
29 : 2021/01/15(金) 10:54:26.467 ID:kZJTsYpNp: ユーザーごとにテーブルを作るって言うサンプルは見たことなかったけど
やはり一般的ではないのだね
35 : 2021/01/15(金) 10:56:35.195 ID:uheAYSi/0: >>29
なんかユーザーにあんまりテーブルの作成・削除を委ねないほうがいいんだよね
バグや不正の温床になる
36 : 2021/01/15(金) 10:56:50.728 ID:mhD1hqvCM: >>29
ユーザごとの履歴なんてSQLで算出するだけだからな
わざわざユーザごとにテーブル作る理由がない
30 : 2021/01/15(金) 10:55:09.923 ID:n/ThO9b90: ユーザ1人ひとりに別個のRDBMSインスタンスを立ち上げればセキュアだよ
33 : 2021/01/15(金) 10:55:43.190 ID:UW/HrYaDM: >>30
サーバも立ち上げようぜ
40 : 2021/01/15(金) 10:58:27.202 ID:UW/HrYaDM: 過去データはDBで残すとまたそれを期間ごとに削除するパッチとか作らないと肥大化するからな
それよりログにしちまえば、一定期間で自動削除とか簡単だし
41 : 2021/01/15(金) 10:58:27.783 ID:kZJTsYpNp: Twitterとかってどうなってんだろうな
あんなのも１つのテーブルでやってんのかな
いくつか分散してたりするのかしら
42 : 2021/01/15(金) 10:59:37.088 ID:CNZkxTAB0: >>41
Twitterは確か内部ユーザーIDの下1桁ごとにテーブル分てスループット向上とかやってたはず