- ユーザーの過去の全ログイン履歴を記録しておく場合って
ログイン履歴テーブル、みたいな１つのテーブルつくって、複数のユーザーで使い回す形になるの？ - 結論は出せないけどいい？
- >>2
ケースバイケースってこと？ - 複数のユーザーで使い回す？
ってのがなんか逆の構造になってない？ - >>3
全くの素人なのでどう逆なのかも分からん - テーブルって一人のために用意するもんじゃねーが
- >>6
ユーザーテーブルは
uid, uname
1, 太郎
2, 次郎
みたいなかんじじゃん？ログイン履歴テーブルは
uid,date
1, 1/3
1, 1/4
2, 1/5
2, 1/6
1, 1/8みたいな？1人に一つのテーブルって考えではない
- >>19
それで大丈夫 - >>19
一人に一つのテーブルではない
ではなく、一人に一つの行ではないでは？
そのテーブル構成で問題ないよ - 逆になんで複数必要なんだ？
- ユーザーIDとログイン日時記録するだけじゃ無いの
- 1テーブルじゃなかったらユーザーごとにテーブル作るってこと？
- 最終ログイン日時だけって話ならユーザーテーブルに記録すれば良いわけだけど
全履歴ってなると数が不変だからユーザーテーブルに入れるとマズイよね - ユーザーテーブルと履歴テーブルが多対多の構造になるね
- いいとも
- │連番│ユーザーID│使用端末│タイムスタンプ│
- 全然多対多じゃねえや
- ユーザーログイン履歴テーブル作ってカラムは
ユーザーID
ログイン日時 - SQL文で全員のログインのデータ集めてきてその場で作れば良くね知らんけど
- ユーザーテーブルには入れないな
ログイン履歴テーブルを新しく1つ作るべき - いったん作ればよくね
- イメージとしてはゴミ箱みたいなのと考えたらいい
家族みんなのレシートを入れていくゴミ箱
つまり「レシートであること」や「いつ入れたか」「誰が入れたか」「KeyのID（自動生成）」これだけでも履歴は成り立つ - それ以外なんかあんの？
- 使用頻度高くねーならログファイルでもいいぞ
- >>23
なるほど
それもありか
ユーザーがめちゃくちゃ増えてきた時に、ログイン履歴テーブルで管理すると大変だったりするかな - >>28
ログインデータは永続保管なの？ - >>31
一定期間超えた分は削除とかでも良いかな
てか多くのサービスであんまり過去の履歴辿れなくなってるのはこういうことか - >>37
ログファイルをaws s3に書き出して一定期間で削除もしくはグレイシアに移行するライフサイクルポリシー設定すれば楽に実装できると思うよ
それならログイン以外のあらゆる処理ログにも対応しやすいし - >>28
保存期間を設けて月次処理とかで古い履歴は削除とかアーカイブ化して別のテーブルに移動なりしてけば問題ないよ - >>28
いいぞ
インデックスつけとけよ - ログイン以外のアクションも履歴残そうぜ
- >>25
いろいろ残したいものあるんだよね
たとえば「ニックネーム」の変更履歴とか - ユーザ情報のテーブルもユーザごとに分けてんの？
- ユーザーごとにログイン履歴テーブルを用意するって設計はないな
全ユーザーが使用するログイン履歴テーブルを1つ用意する方が普通 - ユーザーごとにテーブルを作るって言うサンプルは見たことなかったけど
やはり一般的ではないのだね - >>29
なんかユーザーにあんまりテーブルの作成・削除を委ねないほうがいいんだよね
バグや不正の温床になる - >>29
ユーザごとの履歴なんてSQLで算出するだけだからな
わざわざユーザごとにテーブル作る理由がない - ユーザ1人ひとりに別個のRDBMSインスタンスを立ち上げればセキュアだよ
- >>30
サーバも立ち上げようぜ - 過去データはDBで残すとまたそれを期間ごとに削除するパッチとか作らないと肥大化するからな
それよりログにしちまえば、一定期間で自動削除とか簡単だし - Twitterとかってどうなってんだろうな
あんなのも１つのテーブルでやってんのかな
いくつか分散してたりするのかしら - >>41
Twitterは確か内部ユーザーIDの下1桁ごとにテーブル分てスループット向上とかやってたはず
データベースの設計に詳しい人いる？
VIP
コメント