【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 >>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とかで分からなかったりする場合もあるだろうから歓迎かと ■ このスレッドは過去ログ倉庫に格納されています
