This is a cache of https://b.hatena.ne.jp/entry/s/hatenanews.com/articles/2026/01/29/103000. It is a snapshot of the page as it appeared on 2026-02-10T04:59:35.412+0000.
[B! 設計] そのベストプラクティスは、本当に必要か——シングルDB、削除フラグなし、Devin全社導入に共通するFaciloの設計思想 - はてなニュース
  • はてなブックマーク
  • テクノロジー
  • そのベストプラクティスは、本当に必要か——シングルDB、削除フラグなし、Devin全社導入に共通するFaciloの設計思想 - はてなニュース
  • Twitterでシェア
  • Facebookでシェア

そのベストプラクティスは、本当に必要か——シングルDB、削除フラグなし、Devin全社導入に共通するFaciloの設計思想 - はてなニュース

テクノロジー カテゴリーの変更を依頼 記事元:hatenanews.com
適切な情報に変更
187users がブックマーク コメント 23

    記事へのコメント23件

    • 注目コメント
    • 新着コメント
    ngmy
    ビジネスがスケールするまでは技術的負債など考えずに突っ走るのが正解という話であって、いずれ間違いなく負債になりますよ。負債の返済はその時まで会社が生きていたら考えればいい。

    その他
    kobito19
    人間もAIもシステム理解するのにFK見るし、意図に反して認知コストは上がるんじゃ

    その他
    takeag
    外部キー無しか。パフォーマンス的にはシンプルになるかもだけど、アプリ側の処理はシンプルにならないのでは。 毎回存在チェックするなど

    その他
    turanukimaru
    外部キーが役に立つのは削除してはいけないデータを削除するときなので、極論で言えばマスタに対してしか参照しない、マスタは絶対に削除しない、という方針なら無くてもいいんじゃないかと思う。試してはいない。

    その他
    twotiger
    この手の話ってどれが正解ってわけでもない。議論してる暇があるなら手を動かした方がいい。外部キー使わないのが慣れてるならそれでもいいけど、外部キー使わないのが正解とか押し付けてくる現場は嫌

    その他
    tonocchokun
    ベストプラクティスはみんな同じようにやることでプログラマはどこに行ってもすぐに仕事を始められるって言うことを期待しているんだと思っている。

    その他
    kzm1760
    "属人化しやすい専門の人を作らないようにしたいんです。だからFaciloにはSREもいません" スタートアップあるある。この後にサービス開発が逼迫して障害多発インフラ面倒見切れない、一人目SRE募集！までがセット。

    その他
    red_kawa5373
    最も重要なのは、1つのシステムで、ルールを混在させないこと。「外部キー無し」と決めたのなら、「Aテーブルに紐づくA1テーブルは外部キーを使ってるが、A2テーブルは使ってない」みたいなのは無くす。

    その他
    Goldenduck
    外部キーないと雰囲気でしか外部キーっぽいカラムが何見てるかわからないので確実にしようとするとコードを追うしかなくなる

    その他
    justgg
    外部キーやユニーク制約はしっかりつけておいた方がいい派。そのほんのひと手間を惜しむのはかえってコスパが悪い。

    その他
    kzm1760
    kzm1760 "属人化しやすい専門の人を作らないようにしたいんです。だからFaciloにはSREもいません" スタートアップあるある。この後にサービス開発が逼迫して障害多発インフラ面倒見切れない、一人目SRE募集！までがセット。

    2026/02/04 リンク

    その他
    tonocchokun
    tonocchokun ベストプラクティスはみんな同じようにやることでプログラマはどこに行ってもすぐに仕事を始められるって言うことを期待しているんだと思っている。

    2026/02/04 リンク

    その他
    getcha
    ビジネスのそれ以上の使い方が拡張されない事が見越されている場合は、それでもいいのよ。ビジネス規模や使い方による。目的と手段を適切に。であればどんなのでもいいんよ。

    その他
    myr
    ふーむ？良いのか悪いのか分からなかったがやりたいことは伝わってきた。事故らなければ正義だし事故ったから馬鹿にされる系だろうか。。

    その他
    hirokinko
    記事内にあるスライドを読んでから議論した方が良さそう。興味深い。

    その他
    ngmy
    ngmy ビジネスがスケールするまでは技術的負債など考えずに突っ走るのが正解という話であって、いずれ間違いなく負債になりますよ。負債の返済はその時まで会社が生きていたら考えればいい。

    2026/01/30 リンク

    その他
    bopperjp
    SRE がいないなんてのは組織サイズが小さいからいける話で。いつか「インフラとか運用とか知らないんですけど、アプリはめちゃくちゃ得意です」みたいな人をいっぱい取る時に必要になる。

    その他
    da-yoshi
    削除データを他と同様に扱うケースがある場合はフラグかステータスか別テーブルでUNIONとか。別テーブルにするとFKが問題になるから使わないとか？ 短期的にはいいかもだけど長期的にはデータ不整合が増える危険が

    その他
    cojicoji42b
    “バックエンドエンジニアがインフラのことを常に理解し、その上でいかに監視コストを減らしていくかを考えるべきです。”

    その他
    cpw
    不具合で知らず知らずのうちにデータ不整合起こしてそう。気付けないのが難点だよね

    その他
    Windfola
    頻度低いなら削除フラグは使わない、いざとなったらAI使ってログから復元するし！、はケースによってはまぁありなのかもしれないが

    その他
    twotiger
    twotiger この手の話ってどれが正解ってわけでもない。議論してる暇があるなら手を動かした方がいい。外部キー使わないのが慣れてるならそれでもいいけど、外部キー使わないのが正解とか押し付けてくる現場は嫌

    2026/01/29 リンク

    その他
    turanukimaru
    turanukimaru 外部キーが役に立つのは削除してはいけないデータを削除するときなので、極論で言えばマスタに対してしか参照しない、マスタは絶対に削除しない、という方針なら無くてもいいんじゃないかと思う。試してはいない。

    2026/01/29 リンク

    その他
    toro-chan
    今現在だと生成AIは頭が悪すぎて、とてもじゃないけど相棒じゃない。せいぜい初心者部下程度。早く作ること優先はいいけど、生成AIと相性は良くない。勝手に平均的に組んでしまうので。

    その他
    kobito19
    kobito19 人間もAIもシステム理解するのにFK見るし、意図に反して認知コストは上がるんじゃ

    2026/01/29 リンク

    その他
    soxandcity
    結果整合性とか集約の境界で外部キー貼らないのはわかるが、読む限りそうでもなさそうだ。

    その他
    tasukuchan
    “梅林泰孝”

    その他
    takeag
    takeag 外部キー無しか。パフォーマンス的にはシンプルになるかもだけど、アプリ側の処理はシンプルにならないのでは。 毎回存在チェックするなど

    2026/01/29 リンク

    その他
    nippondanji
    削除フラグなしは良いんだけど、外部キーを使わないのは頂けないな。

    その他
    nguyen-oi
    削除フラグなしとか漢気あふれる設計だな。Devin全社導入も時代の最先端感ある

    その他

    注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

    アプリのスクリーンショット
    いまの話題をアプリでチェック！
    • バナー広告なし
    • ミュート機能あり
    • ダークモード搭載
    アプリをダウンロード

    関連記事

    そのベストプラクティスは、本当に必要か——シングルDB、削除フラグなし、Devin全社導入に共通するFaciloの設計思想 - はてなニュース

    Facilo（ファシロ）は、不動産仲介という業務フローが極めて複雑な領域で、あえて「構成・組織・開発プ...

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

    • red_kawa53732026/02/05 red_kawa5373
    • Goldenduck2026/02/04 Goldenduck
    • shinchi2026/02/04 shinchi
    • ahoj-ahoj2026/02/04 ahoj-ahoj
    • justgg2026/02/04 justgg
    • buell2026/02/04 buell
    • kzm17602026/02/04 kzm1760
    • tonocchokun2026/02/04 tonocchokun
    • ayaniimi2132026/02/03 ayaniimi213
    • shunutsu2-2-242026/02/03 shunutsu2-2-24
    • e10kg2026/02/03 e10kg
    • gotokaeru2026/02/03 gotokaeru
    • okaduka_takayuki2026/02/02 okaduka_takayuki
    • munyaX2026/02/02 munyaX
    • a8422026/02/02 a842
    • yamataku132026/02/02 yamataku13
    • wktk_msum2026/02/02 wktk_msum
    • yoshi_6_172026/02/02 yoshi_6_17
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

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

    いま人気の記事

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

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

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

    新着記事 - テクノロジー

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

    同時期にブックマークされた記事

    いま人気の記事 - 企業メディア

    企業メディアをもっと読む

    はてなブックマーク

    公式Twitter

    はてなのサービス

    • App Storeからダウンロード
    • Google Playで手に入れよう
    Copyright © 2005-2026 Hatena. All Rights Reserved.