完全にDBFlute用語ですが...全ての区分値を一つのテーブルにまとめて管理する方式のことを示します。<(ただの)テーブル区分値>会員ステータスとか製品ステータスとか、それぞれの区分値をそれぞれの独立したテーブルとして管理。ExampleDBはこの方式を採用しています。普通に正規化していくと自然にこの形になる。「区分値」という抽象的な一つのテーブルに管理。「区分値を特定するコード」が必要になる。DBFluteのClassification機能のおさらいhttp://d.hatena.ne.jp/jflute/20090703/1246549011で、この「All-in-Oneテーブル区分値」ですが、よく議論の的になります。採用されているプロジェクトもかなり多く、ひたすらこれにこだわる人もいます。仕事の合間やランチの時間のちょっとした話し合いではとても時間が足りないものです。(わざわざ会議で議題にするほど大げさなものでもないし)で、見つけたのがこの記事です。第3回」がWebで公開http://d.hatena.ne.jp/mickmack/20091114/1258173320ポイントがよくまとまった記事で、まずはこれを互いに読んでから、メリット・デメリットを考慮して現場でどうするか?議論すると良いでしょう。いう資料がとてもとても欲しかったという感じです。リンク先のBlogコメントで自分が二点ほど補足をしています。「OTLTのメリット3つ、デメリット7つ(5+2)」という感じです。Table)」という正式な(!?)名称があるようです。DBFluteでは「区分値」という概念に着目した機能と関連付けるため、ベタベタで直感的な感じで「All-in-Oneテーブル区分値」と呼んでいます。細かい説明等は先ほどのリンク先を読んで下さい。「コード検索のSQLを共通化できるため,コーディングを簡略化できる」ですが、アプリケーション開発者からの視点で言えば、ほとんど極小のメリットと感じられます。「いざ間違ってしまった時に間違いに気付くスピード」では劣るかと思います。サロゲートキーを使っていないような場合は複合FKでの関連となり、なおさら煩雑で間違い易いSQLを書かなければならなくなります。自分がBlogコメントで補足した:「テーブル間の関係が全て同じような方式で関連付いてる方がわかりやすい」という意見とこのメリットがまさに相反します。小さいメリットというように感じます。「ディベロッパーのメリット」ではないことに気付きますDB設計をよくやるのでわかるのですが、ERDツールでテーブル一個作って、それぞれのカラムを入力して、和名を付けたり、説明を付けたり、って、確かになかなか面倒なものです。ERDが大きくなって来て、テーブルの居場所に困ることもあります。テーブルがごそっと減るのは「DB設計者にはとてもラクチン」なわけです。それは「ディベロッパーにとってのうれしいことではない」ですね。自分がBlogコメントで補足した「表裏一体のデメリット」を考えると、どちらかというとディベロッパーにとってはうれしくない状況です。区分値特定コードなんて意識しなくていいからです。それだったら、DB設計者はちょっと我慢して頑張って、(もちろん、ちゃんと工数をもらって)ディベロッパーたちに気持ちよく実装に集中してもらった方が、システム開発全体のことを考えたら圧倒的に良いと考えます。それに、区分値の閲覧性の問題であれば、DBFluteのSchemaHTMLで、SchemaHTMLの区分値一覧で、見ることができますしね。要は...「管理がしやすい・しにくい」という問題は、ツール次第(工夫次第)でどうとでもできるんですね。なんか似たような話が昔ありましたね。AdditionalForeignKey」FK制約の付与に関することで、そこでも「工夫次第」って要素が出て来ています。いうことで、唯一挙げられている3つのメリットも、もちろん「メリットが無い訳じゃない」ですが、そこまで厚いメリットではないかな、という感じです。何かしらの対策をして、しっかりマネジメントすることが大事です。ちなみに自分がDB設計するときは「All-in-Oneテーブル区分値」は採用しません。対費用効果的に良いものであると思えないからです。非常に地味な作業ですが頑張ってそれぞれの区分値のためのテーブル作ります。自分が見て来た「All-in-Oneテーブル区分値」採用の現場では、デメリットが丸出しな状態がかなり多かったです。ディベロッパー経験もたくさんありますが、それはもう実装しづらかった覚えがあります。余談こういったテーブル設計に関する記事というのはあまり世にありません。正規化の記事は多いですが、こういった現場寄りの細かい話はほとんど見つけることができません(ないわけじゃないけどまあ少ないかな)。それだけに、今回紹介した記事はとてもとても貴重だと考えます。他にもとても良い記事があるので、どんどん読んでみると頭の中でもやもやしていたものが綺麗に整理できるかもしれません。幾つか注意点があると考えます。時代の違い<アプリ寄りなDB設計者、インフラ寄りなDB設計者>単独に話題にしている記事があります。基本的な考え方はこちらをご覧下さい。関連:「もうDBはこうなってますので」はもったいない」ここで言いたいのは、ちょっと対象とする場所を変えた話(世の中の記事に着目)。完全ではないことが多いのでご注意下さい、という話です。(別に今回の記事がそうだってわけじゃなくて、共通的な意味合いで)全ての立場の視点に立ってる人なんていませんので当然かと思います。大事なのは、読み手がそこを踏まえた上で自分の知識とすることです。「鵜呑み」ではなく、あくまで「参考」にするということです。今日自分が書いた記事も「鵜呑み」にしてはいけません。参考情報として自分の知識として保持しておくのが良いのです。<時代の違い>もう一つ、時代という違いがある場合があります。最近書かれた記事でも、昔の時代で正解だったやり方をずっと引きずってる場合もあります。今でもあまり変わっていないように思えます。それを取り巻くインフラ環境は大きく大きく変わって来ました。5年前と今でも大きな違いを感じるくらいです。想像もつかないくらい変わっているでしょう。昔の環境に依存した考え方で今の環境には通用しない考え方もあるでしょう。「FK制約付けるとDB内でチェックが走るからパフォーマンスが...」という主張を聞くことがありますが、そんなこと言ったらそもそもアプリもJavaで実装するんじゃなくてC言語で実装した方がいいよって話もあります。トランザクション数の多いシステムもFK制約付けて運用してるのも多く見ていますが、FK制約が問題になってるのを見たことありません。本当に考慮すべき超絶トランザクション数のシステムはあるかと。それは全体からすると稀で、気にする必要のある場面は多くないかと。(気にする必要がある箇所があってもそれは局所的にFK外せば良いし)でも、確かに10年前は気にする必要があったのかもしれません。(実際に先輩エンジニアからそういう話を聞きます)そして、今の正解も10年後は間違ってる可能性もあります。自分で考えて頭に入れる必要があるかと思います。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。