記事へのコメント53

    • 人気コメント
    • 新着コメント
    tmatsuu tmatsuu 追記の部分も外部キー制約はON DELETE SET NULLなりSET DEFAULTを使えば適用できるよ。その状況で適用できないのは外部キー制約ではなくNOT NULL制約な気がした。

    2020/06/22 リンク

    その他
    rryu rryu 要は依存関係のないエンティティ間のリレーションの時ということだと思うが、DB的にはNULL可な外部キーカラムというだけで外部キー制約が付けられない訳ではない。

    2020/06/21 リンク

    その他
    kiririmode kiririmode “結果整合性を求める用途では外部キー制約は使えない。トランザクション整合性のある境界内では使える”

    2020/06/21 リンク

    その他
    sds-page sds-page 基本論理削除でデータの入れ替えする時の邪魔にしかならんから外部キー制約は使わないかな

    2020/06/18 リンク

    その他
    everybodyelse everybodyelse 物理削除も論理削除もやめて、全てのデータは必ず残してステータスだけで管理するのが良いような気がしている。削除ではなくアーカイブとして履歴テーブルに複製していく感じ。個人情報は適当なデータで上書けばいい

    2020/06/18 リンク

    その他
    juve534 juve534 「外部キー制約はとりあえずつけた方が良い」というイメージでしたが、トランザクション境界を考えると、一概にそう言えないんですね

    2020/06/18 リンク

    その他
    takeshiketa takeshiketa 外部キー必須とは言えないみたいなのに理由付けするの、Rails普及期によくあった。それと同じとは言わないけどさ。

    2020/06/18 リンク

    その他
    yojik yojik DDDの集約の考え方を守るためだけに、RDBMSのデータ整合性を守るFKをオミットするする問題(そもそも両者相容れない存在なのかも)。あと商品に関してはそれとは別問題で売上明細用のスナップショットが必要だと思う

    2020/06/18 リンク

    その他
    mitchell1983 mitchell1983 ON DELETE SET NULL

    2020/06/18 リンク

    その他
    moro moro 昨日から何度か読み返してみたけど、やっぱり外部キー制約あったほうがいいじゃんね、という気持ちになる。もとの食べチョクさんの意見に賛成で、現在は迷ったらつけるでいいんじゃないですかね

    2020/06/18 リンク

    その他
    letitride letitride この手の話し、FKもnullableも削除フラグも必要があれば使用するし、必要なければ使用しないと考えておけば気が楽。記事の例でいうと商品の変更履歴を残しておくという要件があれば、 また違ってくるし、設計大事

    2020/06/18 リンク

    その他
    deztecjp deztecjp 出した例に問題があると、本題そっちのけで例へのツッコミばかりになるパターン。/「初心者はとりあえずこうしておこう、後で苦労するけど致命的ではない」的な知恵がほしいけど、「そんなものはない」で終了か。

    2020/06/18 リンク

    その他
    k-wacky76 k-wacky76 どうしてもFK付けたくなければ、売り上げ履歴テーブルと商品履歴テーブルにレコード移して、現行テーブルは容赦なく削除かな

    2020/06/18 リンク

    その他
    kae1990 kae1990 まぁ外部キー制約は多くの場合不要だろう。整合性が取れなくなるのは運用が間違ってるケースだ

    2020/06/18 リンク

    その他
    nakag0711 nakag0711 商品価格をマスタからコピーしないで商品コードだけ記録するのは初心者のよくやるミス

    2020/06/18 リンク

    その他
    lifeisadog lifeisadog 削除したい時って間違えて登録しちゃった時とかだよね

    2020/06/18 リンク

    その他
    Error401 Error401 この記事の内容を受け入れる前に、「結果整合性」とは何かを調べ、SQLアンチパターンの「4 章 キーレスエントリ(外部キー嫌い)」を読むことをお薦めします。私はこの記事は害悪だとすら思う。

    2020/06/18 リンク

    その他
    aike aike FK制約の話というより履歴テーブルは正規化しすぎないという設計頻出パターンの話か。追記にあるけど悩ましいのは退会して個人情報削除請求があったとき。

    2020/06/18 リンク

    その他
    twotiger twotiger 外部キー制約は滅多に使わないな。仕様変更耐性やデータの一括操作時に足かせになる。商品レコードを削除する(論理でも)ケースはまずなくて、ステータスカラムでユーザーに非表示にするのが普通のECサイトだと思う

    2020/06/18 リンク

    その他
    ys0000 ys0000 斜め読みしたけど、売り上げの明細に入った時点で元の商品と分けなければならない。廃盤、価格改定、増税、キャンペーン値引き等々。商品がスキーマで売り上げがインスタンスって感じかなぁ。

    2020/06/18 リンク

    その他
    yamadadadada2 yamadadadada2 例の良し悪しは置いといて、変更容易性を保った設計実装は意識したい。制限があればいいってもんじゃないという主張は同意

    2020/06/18 リンク

    その他
    shikiarai shikiarai 終売、絶版、削除フラグを用意しないとゲロ吐きそうになるよね。画面上永遠に入荷待ちとしか表示できなくなったりする

    2020/06/18 リンク

    その他
    mohno mohno 追記されてるが例が悪いというか、「忘れられる権利」も個人情報消せばよいのでは。アカウント名の再利用を考えるなら、それで制約かけちゃいかんというのはありそうだけど、それはそれで運用が難しくなる気はする。

    2020/06/17 リンク

    その他
    ymhb ymhb 舛添要一に空見したわ

    2020/06/17 リンク

    その他
    lapk lapk 追記読んだけどON DELETE SET NULL使えばいいのでは?参照先データ単独で削除したい弱い整合性だから外部キー貼れない理由がよくわからん。参照先がある場合もあればない場合もあるは外部キー貼っても貼らなくても文字数

    2020/06/17 リンク

    その他
    chinpokomon_master chinpokomon_master 言いたいことはわかるが本人も書いてる通り本当に例が悪かった。そして何かを否定する時は慎重にならないといけない。誤解されてから「本当はこういうつもりだった」と追記したところで誰も見てはいないだろう。

    2020/06/17 リンク

    その他
    dagama dagama データ設計なんてのはどうせすぐに変わっていくものだから制約は無いに越したことはない アプリ側単体テスト(DBへのI/O部分含む)の邪魔になったりもするし

    2020/06/17 リンク

    その他
    sinsoku sinsoku 外部キーあるレコードも削除できるし、説明があっていない気がする。

    2020/06/17 リンク

    その他
    circuit_breaker circuit_breaker https://note.com/masuidrive/n/n2d631eee2bef これを思い出した。泥臭い運用を確実に避けることが前提かもしれないけど、自分には自信ないなー…

    2020/06/17 リンク

    その他
    uva uva こういう判断の連続・積み重ねなのでソフトウェア開発の難しさがわかる

    2020/06/17 リンク

    その他

    関連記事

    外部キー制約は何も考えずに適用するとよくない - かとじゅんの技術日誌

    このブログ話題になってますね。制約を付けること自体はよいことだけど、無目的適用すると害も生じ...

    ブックマークしたユーザー

    • KashEight2021/04/03 KashEight
    • thotentry_hatebu1972020/12/12 thotentry_hatebu197
    • ikesyo2020/08/12 ikesyo
    • nyamadori2020/08/09 nyamadori
    • dnskimox2020/08/01 dnskimox
    • kwy2020/07/31 kwy
    • a2ikm2020/07/21 a2ikm
    • keensyo2020/07/07 keensyo
    • dhesusan46492020/07/06 dhesusan4649
    • somathor2020/06/28 somathor
    • supermomonga2020/06/24 supermomonga
    • tmatsuu2020/06/22 tmatsuu
    • mjtai2020/06/22 mjtai
    • hbKOT2020/06/21 hbKOT
    • rryu2020/06/21 rryu
    • kiririmode2020/06/21 kiririmode
    • fumikony2020/06/19 fumikony
    • tg30yen2020/06/19 tg30yen
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

    同じサイトの新着をもっと読む

    いま人気の記事

    いま人気の記事をもっと読む

    いま人気の記事 - テクノロジー

    いま人気の記事 - テクノロジーをもっと読む

    新着記事 - テクノロジー

    新着記事 - テクノロジーをもっと読む

    【MMMMORPG】Ingress攻略(Wiki風味)【大規模社会実験】: Ingress Ver1.104.1

    1 user https://ingressjp.blogspot.com/

    「PySpark」: Alibaba Cloud CentOSインスタンスにPySparkを設定する - Qiita

    1 user https://qiita.com/