気に入った記事をブックマーク
- 気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
- 記事を読んだ感想やメモを書き残せます
- 非公開でブックマークすることもできます
エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント50件
- 注目コメント
- 新着コメント
buhoho
"商品単体での削除ができません" うーん。そのための制約なので狙い通りの動きっぽい。商品が存在しない売り上げって考えられないので、自分なら商品単体の削除は許さない。例が悪いだけなのかな…
crexist
ちょっと例がよくない気がします。売り上げに会員IDを紐付けて購入履歴が見れる様にするという例であれば、その際会員IDが FK だと退会時に会員を物理削除することができなくなるという話にできて納得感があるかと
khtno73
売上というか関連明細発生した商品削除できない(しちゃいけない)のは販売購買在庫の業務システムでは割と一般的なので、こんな例出せばそらブコメは紛糾する。終売/終息フラグか年月日入れて新規取引発生不可よね。
night_face
ネットショップで働いているけど、商品を削除ってどういう時？！大体データは残して販売休止にすると思う。同一商品を出品し直す場合、過去の売上連動できないから別IDで出品するし、そのユースケースが想定できない
nminm
「商品も勝手に消されると困るから制約があっても良いのでは？」みたいなコメントを書かれている方は、実際に商品を消す処理を想定してみるといいかもですね。（より重要な）売上詳細もいじる必要が出てくる怖さ。
tmatsuu
追記の部分も外部キー制約はON DELETE SET NULLなりSET DEFAULTを使えば適用できるよ。その状況で適用できないのは外部キー制約ではなくNOT NULL制約な気がした。
everybodyelse
物理削除も論理削除もやめて、全てのデータは必ず残してステータスだけで管理するのが良いような気がしている。削除ではなくアーカイブとして履歴テーブルに複製していく感じ。個人情報は適当なデータで上書けばいい
yojik
DDDの集約の考え方を守るためだけに、RDBMSのデータ整合性を守るFKをオミットするする問題（そもそも両者相容れない存在なのかも）。あと商品に関してはそれとは別問題で売上明細用のスナップショットが必要だと思う
letitride
この手の話し、FKもnullableも削除フラグも必要があれば使用するし、必要なければ使用しないと考えておけば気が楽。記事の例でいうと商品の変更履歴を残しておくという要件があれば、 また違ってくるし、設計大事
deztecjp
出した例に問題があると、本題そっちのけで例へのツッコミばかりになるパターン。／「初心者はとりあえずこうしておこう、後で苦労するけど致命的ではない」的な知恵がほしいけど、「そんなものはない」で終了か。
Error401
この記事の内容を受け入れる前に、「結果整合性」とは何かを調べ、SQLアンチパターンの「4 章 キーレスエントリ（外部キー嫌い）」を読むことをお薦めします。私はこの記事は害悪だとすら思う。
twotiger
外部キー制約は滅多に使わないな。仕様変更耐性やデータの一括操作時に足かせになる。商品レコードを削除する（論理でも）ケースはまずなくて、ステータスカラムでユーザーに非表示にするのが普通のECサイトだと思う
mohno
追記されてるが例が悪いというか、「忘れられる権利」も個人情報消せばよいのでは。アカウント名の再利用を考えるなら、それで制約かけちゃいかんというのはありそうだけど、それはそれで運用が難しくなる気はする。
chinpokomon_master
言いたいことはわかるが本人も書いてる通り本当に例が悪かった。そして何かを否定する時は慎重にならないといけない。誤解されてから「本当はこういうつもりだった」と追記したところで誰も見てはいないだろう。
circuit_breaker
https://note.com/masuidrive/n/n2d631eee2bef これを思い出した。泥臭い運用を確実に避けることが前提かもしれないけど、自分には自信ないなー…
oktnzm
この場合でも制約つけない設計もあるだろうが設計思想の話になる。そういう意味では不適切な例。個人的にはパフォーマンスの問題で現行商品と過去分を分けるというのはやる。でも完全削除はやらない。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
いまの話題をアプリでチェック！
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌
このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じ... このブログが話題になってますね。制約を付けること自体はよいことだけど、無目的に適用すると害も生じると思います。 無目的という言い方はおかしいな…。外部キー制約をどのように使えばいいのか、逆にどんなときに使うとまずいのかを考えてみたいと思います。 tech.tabechoku.com 例えば、これ。外部キー制約はできるだけ付けるとか、何も考えずに付けるとよくないと思います。 外部キー制約は、可能な限りつけるようにしています。 DBが別れている場合、外部キーはもちろん貼れないのですが、そうでない場合はとにかく何も考えず貼っています。データベース設計の際に気をつけていること - 食べチョク開発者ブログ テーブル設計をシミュレーションする いいたいことの結論はこれ。以上終了なのですが、もう少しわかりやすく書いてみよう。 何も考えずに外部キーを貼るのは良くないな。トランザクション境界の外で結果整合性
ブックマークしたユーザー
すべてのユーザーの
詳細を表示します
詳細を表示します
2020/06/17 リンク