【PHP】Laravel【フレームワーク】 Part.5
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
※前スレ
【PHP】Laravel【フレームワーク】 Part.4
https://medaka.5ch.net/test/read.cgi/php/1613209188/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured laravelがphp8に対応してるのと関連ライブラリがphp8に対応してるかは別だけどな
php7.4から8.0へよ後方互換無い変更はあんま無いから普通にphp8使って問題になるケースはほぼ無いだろうけど お前ら.envの話はどうした？
そのために立てたスレだろちゃんとやれよ 前スレで結論出てると思うが君がまた続けたいなら好きにすれば良い laravel-vite出たのか
ネタじゃなくlaravel-mixは使う理由が無くなるな 別にLaravel-Mix使う人をディスるつもりは無いんだけど、公式に「webpackより設定が容易ですが80%くらいの用途しか満たせません」って書いてある時点であえて選ぶ理由は無いよね。
いくらwebpackの設定が簡単になるといってもvueやreactの公式テンプレでも事は足りるし、viteの以前から使う理由が無い。しかもwebpackのバージョン古いし。
といっても俺はLaravel-Mixを使ったことないから、80%の用途ってのが具体的に何が問題になるかは分からないんだけど。
ちなみに、Laravel-MixってバックエンドにLaravelを使う必要ないんだよね。
Laravel-viteもそうだけど、独立して使えるのになんで名前にLaravelってつけたんだろ。 結構ゴリゴリSPAで使ってるけどその20%にぶち当たった事は今のところないな おい過疎ってるぞ、スレ立てたやつは責任持って話題出せよ SESSION_LIFETIMEってlast_activityからの時間ですよね？
例えば120分の設定だった場合、ログインから60分の時点でページ遷移するとそこから120分非アクティブでセッション破棄されてログアウトされる
これをログインからの時間にすることはできますか
120分の設定でログインから60分の時点でページ遷移してもそこから60分(ログインから120分)非アクティブでセッション破棄されてログアウトされる
というようにしたいです 間違えた
120分の設定でログインから60分の時点でページ遷移してもそこから60分(ログインから120分)でセッション破棄されてログアウトされる
です
非アクティブかどうかは関係なし ワッチョイとか中途半端なことしないでIPまで表示するスレたてろや無能！ 一年前のスレなのか
viteが正式採用された今、感慨深いね 退会を論理削除で対応するusersテーブルって、どう設計するのがいいのかね？
mailアドレスをユニークにしちゃうと
・再登録時に削除フラグの削除で登録させると過去のリレーションが生き返る
・リレーションを復活させない仕様にすると、ユニーク制限で弾かれる
リレーションは復活させない仕様にしようと思っていて、少し調べると create_at と複合ユニークで設計する方法がいくつか出てきた
ただ、それならユニーク制限を外してしまったほうが良いような
みんなどうしてる？ 苦肉の策で削除フラグを0か0以外かにして
削除フラグとIDでユニークにしたりとかしてたな
フラグを立てる時はそのメアドの削除フラグの最大値+1で立てればいいし > 削除フラグの最大値+1
これなんか良さげだねぇ（たしかに苦肉の策だけど）
これ元に設計はじめてみる
ありがとう フラグってのはbool型を意味するのに、そこに1より大きい値を設定する時点で設計として破綻している
一般的に論理削除フラグと主キーの組み合わせでユニークチェックする場合、論理削除フラグにはnullを設定する
なぜならnullはDB上全てユニークな値と認識されるからね
本当に論理削除が必要なのかはちゃんと詰めていくべきだけど、
必要ならLaravelが標準で提供している論理削除の仕組みに乗るほうが良い
特にフラグに1より大きい値を与えて複合ユニークを実現しようと考えるスキルの低い人間にはね >>59
>>60
ふたりとも言ってることがよくわからないですが、コメントありがとうございました deleted_atとemailの複合ユニークで設計してみようかと思います
実績でもっと良い方法があれば引き続き教えて下さい 退会会員テーブルを作るのはどうなの？
会員テーブルは状態（停止｜有効｜退会）カラムを用意して。
会員が退会申請したら、状態を「退会」にして
退会会員テーブルに会員IDと退会日時を追加する。
そして「退会申請後○日後に会員データを削除する」
としたら、個人情報保護の観点でも問題がないし
復活させたい会員は復活できる。
mailアドレスをユニークにしても、
リレーションは復活しない（関連データを1から追加する）ようにもできる >>63
ググった中に提案いただいた設計の議論がありました
soudai.はてなぶろぐ.com/entry/2018/05/01/204442
少し冗長な気もしますが、ブクマ見ると結構似た設計にされている方がいるようですね
もう少し調べてみます
ありがとうございます >>64
見てきたけどこれじゃないよ。さすがに冗長すぎる
俺の提案は単に「退会用のテーブルを作って、退会時の情報を記録しましょう」だから。
とりあえず色んなやり方があるから、納得行くのを選択して試すといい 例えば、黒田努のRuby on Rails 6 実践ガイドでは、論理削除を採用していない。
単に削除しているだけ
customer = Customer.find( params[:id] )
customer.destroy!
論理削除は、広範囲に他の検索条件にも影響が及ぶ。
それが難しい。
日時のバッチ処理もしないといけない
うかつに論理削除をするなと書いてある、DB の本もある >>65
違いましたか。失礼
この記事、マサカリ（？）がそこそこ飛んできていて、その中のいくつかを、提案いただいた内容と勝手に結びつけてしまいました
納得行くものはなかなかないですねぇ
困った笑 >>66
せっかくのRDBなので物理削除したくなるのはわかりますが、今どき「退会即物理削除」は無理だと思います
今回は論理削除は必須条件なので、もし条件に合う設計案があれば教えて下さい 論理削除は、広範囲に他の検索条件にも影響が及ぶ。
それが難しい
普通に削除して、別の削除済み用のテーブルへ追加しておけば？
そうすれば、他の検索条件には影響が及ばない 「検索条件 AND 削除フラグがFalse」とか、
すべての検索条件において、一々削除フラグを考慮するのが面倒
こういうシステムは保守できない > 普通に削除して、別の削除済み用のテーブルへ追加しておけば？
こちらができるのであれば、論理削除の影響範囲は洗い出せた状態なのであまり分離するメリットは無いように思います
> すべての検索条件において、一々削除フラグを考慮するのが面倒
Laravelだとデフォルトがそういう仕組みになっています
仕組み自体はそれほど難しいものではないのでRailsでも実装されてそうですけど >>70
Laravelなら自動でその処理をやってくれる
ただし、クエリビルダ使う場合は自分で条件に気を付ける必要があるぞ 例えば、Rails では単一テーブル継承という機能がある
顧客が自宅と勤務先を持つ場合に、
自宅と勤務先の列は、大体同じものであるため、
自宅と勤務先を、住所という同じテーブルから派生させて、
Railsが裏側で、自宅と勤務先を切り替える機能
自宅 < 住所
勤務先 < 住所
type=自宅とか、type=勤務先などの検索条件を、SQLに入れなくて良い >>70
削除フラグじゃないけど、俺はそうしてるわ
会員の有効・無効とか、記事の表示・非表示とか。
別テーブルにして有効か調べてから
データ抽出するよりも明らかにパフォーマンスは良い
>>73
WordPressでもその設計だけど、アンチパターンだよな
といいつつ、同じ設計を採用する場合も多々あるけどw >>73
コメントの趣旨がわからなかったのですが、どこで単一テーブル継承を使用すると良いということだったのでしょうか？
あとそれはLaravelで実装できるものなのでしょうか？ >>74
有効・無効/表示・非表示をそれぞれ別テーブルに充てているということでしょうか？
あまり大規模な構築はやっていないので、冗長に思えます。
パフォーマンスに言及されていますが、どの部分（あるいはどの程度）でパフォーマンスに差が出ます？
ぜひ教えて下さい。指標の参考がほしいです >>75
Rails にも、単一テーブル継承といって、
フラグをRailsが裏側で、切り替えてくれる機能があるというだけの話
削除フラグとは関係ないけど >>77
> 仕組み自体はそれほど難しいものではないのでRailsでも実装されてそうですけど
こちらに対してのコメントだったのですね
理解できました
＊スレチな話題に誘導してしまい申し訳ありませんでした
回答、ありがとうございます >>78
ソフトデリートのdeleted_atとmailの複合ユニークだとダメですね
DBとしては重複登録できてしまう
>>57 の退会回数とmailの複合ユニークがDBとしては正なんですかね
（0がアクティブってのが嫌なんですよねぇ）
もう少し悩んでみます 上でnullはユニークとして扱われるって説明をしているのに、よく分からないの一言で終わってるやつ、一生エンジニアとして半人前のままで終わりそう ソフトデリートって論理削除？
そんなのバッドノウハウとして知れ渡っていてもうオワコンだろ、バグの基になるからやめた方がいいぞ >>59
これ見た感じ削除したものを復元する前提で考えるあたりマジでバッドノウハウだな ソフトデリートは世界一の堅牢な業務システムでも採用されてるからバッドノウハウじゃねえよ >>82
SQLアンチパターンをちゃんと読もうな
どんなものにでもそれが必要なケースは必ずある
問題は、論理削除のように使うことで副作用を生み出してしまう設計を、
他に手段がある中でも思考停止で使ってしまうことにある >>81
そこは理解できました
頂いたコメントのおかげで、deleted_atとmailの複合ユニークを NULLS NOT DISTINCT のオプション設定できればイケそうと判断しましたが、調査調査の結果、MySQLだとダメっぽいのであきらめました。PostgreSQLならイケたかもしれません
理解できなかったのは
> フラグってのはbool型を意味する
> 一般的に論理削除フラグと主キーの組み合わせでユニークチェックする場合、論理削除フラグにはnullを設定する
boolなのにnullをフラグとして利用する前提？？？
かなり混乱して未だに理解できません
今は判定用のカラムを作る方向を模索しています
https://yaba-blog.com/laravel-softdelete-unique/
https://qiita.com/taruhachi/items/bb78d92efa67b6936201
良い案があればご教示ください >>86
56だわ...なぜ63なんてかいたんだろ... 句点Rubyおじの居場所をこっちにも作ってあげてくださいw まずは連番問題からだな
問題だと思っているのruby爺だけだがｗ 今でも未定義変数のまま利用するというケースが無かったし
厳密にエラーになるならそれはそれで良いかと思う
typoとかで分からなかったりする場合もあるだろうから歓迎かと 
