記事へのコメント27

    • 注目コメント
    • 新着コメント
    el-condor
    アプリで十分な制約を、という説もあるけれど、アプリよりデータの方が寿命が長いので、DB側で制約を設けるのは長期的に考えると割に合うはず。テストだって依存関係きちんと揃えた方がやりやすいはず

    その他
    jumperson
    RDMの普通の話。Railsとかのフレームワーク使ってると忘れがちなのかもね。

    その他
    pascal256
    ミドルウェア(RDB)で出来る事をアプリで頑張って保障するのは基本的に間違ってるので、外部キーも一意制約も特別な理由が無い限り使いたい。むしろ使わせて!

    その他
    shag
    正しい正しくないという切り口だと、外部キー制約はあった方が圧倒的に正しいので致し方ない。

    その他
    koyancya
    DB のシステムカタログのテーブルを再帰クエリ(あるなら)で走査すれば全テーブルの依存順を取得できるので、その順番でデータを投入すれば容易にテストできますよ

    その他
    ngmy
    ngmy “最悪DBが守ってくれる”という安心感があるとアプリ側も気が楽ですよ。

    2017/08/05 リンク

    その他
    Vaduz
    DB アンチパターン「FK 制約を使う」

    その他
    vanbraam
    RDBMSを単なる信頼性の高いデータストアとしてロギングに使う,という手法があるので,それに何か問題があるのかと思ったら,単なるDB設計アンチ・パターンだった;そしてその常識すらないブコメに闇を感じた

    その他
    muamqm
    はてぶコメの意見が二分しとる。要はどっちでもいいってことか

    その他
    kk6
    最近、今回はFK使わないでくれと言われて作ったやつ超だるかった

    その他
    easy-breezy
    来週やる

    その他
    joe-re
    わかりがある

    その他
    sifue
    DBの制約は使ったほうが良い。本当にこれしないと後悔する。

    その他
    komutan1
    DDDやり始めてから外部キー制約を再び使うようになった。集約のルートが親になるし子だけ作ろうとしても入らない。オブジェクトのライフサイクルと境界とも一致する。

    その他
    te2u
    te2u 昔からずっと指摘されているアンチパターン。確かSQLアンチパターンにもあった。/DBのテーブル、制約、リレーションはアプリケーションのデータ構造を表現する。それは、制約も含めて適切に表現すべきもの。

    2017/08/04 リンク

    その他
    kabochatori
    外部キーは実際にDBに設定するかどうかはともかく設計上は必要

    その他
    t-wada
    t-wada 外部キー制約を使おうという話。圧倒的に正しい。

    2017/08/04 リンク

    その他
    koba789
    koba789 個人的な意見としては「DBMS 実装できる筋肉があるならアプリケーションコードで整合性担保してもいいと思いますが、そもそもトランザクション分離レベルを意識して整合性チェックのコードを書けますか?」です

    2017/08/04 リンク

    その他
    oakbow
    oakbow Check制約までやれとは言わないけど、FKや一意制約、Not Null制約つけるのは昔から当たり前だと思ってる。んだけど、ブコメ見る限りまだそうじゃない人多いんだ…という印象。Rails4.2未満のFKなら分かるんだけど。

    2017/08/04 リンク

    その他
    faibou
    faibou 私も外部キーは使わないなぁ。メリットを感じたことが一度もない。まぁ言いたいことはわかるんだけど、レコード直接いじること多い人は特にそう感じると思う。

    2017/08/04 リンク

    その他
    hdampty7
    外部キーはクソ。テストがだるいし、データの登録順とかでも落ちるようになるから。ユニークキーだけはないとアプリケーションのバグがシステム全体の破壊に成り兼ねない。

    その他
    twainy
    twainy MySQLで頑張るのはいいけどrailsで頑張るのは闇しか感じない

    2017/08/04 リンク

    その他
    tripleshot
    アプリ側か、制約かって二元論じゃなく、RDBMS を単なるデータストアと見てると、DB側の制約で楽にできるはずの事も忘れちゃいがち (なので両方で上手くやろうね) って話かな。それでも個人的にはFKは使わないな。

    その他
    moro
    moro fk制約は、テストで使うデータを事前にYAMLとかに書いておくというRailsのfixturesの仕組みと食合せが悪かったけど、フィクスチャリプレースメントgemによって実用性がもどってきた気がします。

    2017/08/04 リンク

    その他
    turanukimaru
    turanukimaru 外部キーは論理的には正しいんだけどテストが超辛いのよね。テストデータ投入するときに関連するデータが全部必要になる。ストアドは思想的には好きなんだけど言語が古すぎて困る。

    2017/08/04 リンク

    その他
    hisaju
    hisaju え、アプリ側制約からSIer全盛期に流行ってたDB側制約の流れにまた戻るの??個人的には外部キー参照地獄は好きじゃないんだよな。ちなみにこの流れでストアドおじさんも復活するのかな。

    2017/08/04 リンク

    その他
    akulog
    パワーワード→"ボタンは1回だけ押してください"

    その他
    kymmt90
    RDBMSの制約を使うと "データを信頼できる", "誤りに早く気付ける"

    その他

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

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

    関連記事

    Rails アンチパターン「RDBMS を単なるデータストアとして扱う」 / Rails Anti-pattern RDBMS is not more than datastore

    RDBMS は便利だからもっと使っていきましょうというお話。 表参道.rb #25 Rails アンチパターン で話し...

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

    • techtech05212024/01/22 techtech0521
    • tsumuchan2017/09/24 tsumuchan
    • Hiro_Matsuno2017/09/24 Hiro_Matsuno
    • urouro_n2017/09/12 urouro_n
    • kwy2017/09/02 kwy
    • goyachanpuru2017/09/02 goyachanpuru
    • el-condor2017/08/28 el-condor
    • tsub5112017/08/28 tsub511
    • jumperson2017/08/19 jumperson
    • dowhile2017/08/18 dowhile
    • itkq2017/08/14 itkq
    • rrreeeyyy2017/08/14 rrreeeyyy
    • mitsuto2017/08/14 mitsuto
    • ryota-172017/08/11 ryota-17
    • jqk772017/08/11 jqk77
    • snaka722017/08/09 snaka72
    • pascal2562017/08/09 pascal256
    • mooonymann2017/08/09 mooonymann
    すべてのユーザーの
    詳細を表示します

    同じサイトの新着

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

    いま人気の記事

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

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

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

    新着記事 - テクノロジー

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

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

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

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