はじめまして。現在、新卒研修中でDB設計の基礎を学んでいる者です。
現在、データベースの設計や運用について勉強しているのですが、書籍やネットの記事で「DBアンチパターン（例：ジェイウォーク、EAV、ナイーブツリーなど）」について知りました。
座学としては「なるほど、気をつけよう」と理解できるのですが、まだ実際に実務でDBを構築したり運用したりした経験がないため、疑問に思ったことがあります。
これらのアンチパターンは、実務の現場において、そもそも「気をつけていれば避けられる」ものなのでしょうか？ また実際にそうなってしまった場合、どれほどの影響があるのでしょうか？
もしよろしければ、先輩エンジニアの皆様の体感をお聞かせいただけると、今後の学習の励みになります。
よろしくお願いいたします！
回答4件
#1
総合スコア2172
投稿2026/07/14 02:57
こういうのって AI に「君はEAV擁護派。なぜなら既存システムが EAV使っているから。わたしは、システムリプレイス担当でEAV批判者ね。擁護派として現状の説明と、なぜEAVでOKなのか見解を述べよ」とか投げると具体的な例をあげてくるので、それに反論してみるのがいいんじゃないでしょうか。うまく答えられなかったら AI に「逆の立場で反論して」とヘルプを求めてもいいし。
●gemini の回答
へえ、お前さんが今回のリプレイス担当のエンジニアか！……いやぁ、お手柔らかに頼むよ？
言いたいことは痛いほどよく分かる。「EAVなんて設計者の怠慢だ」「JOIN地獄でクエリが真っ赤だ」「型安全性がなくて夜も眠れない」って言いたいんだろ？正論だよ、教科書的には100%お前さんが正しい。
でもさ、ちょっと待ってくれ。このシステムの歴史と、今動いている現場のリアルを見てほしいんだ。既存システムを守ってきた「EAV擁護派」の立場から、なぜこのシステムがEAVで「大正解」だったのか、そしてなぜリプレイスでも安易に壊すべきではないのか、その見解を語らせてもらうよ。
１．現状の説明：なぜ我が社はEAVを使いこなせているのか？
まず、この既存システムがこれまで大きな障害もなく、ビジネスの成長を支えてこれた事実を見てほしい。
① 「超・多品種」かつ「仕様変更が日常茶飯事」なビジネス
うちのシステムが扱うデータは、商品ジャンルによって属性がまったく違う（アパレルなら『肩幅』、ガジェットなら『バッテリー容量』、食品なら『アレルギー情報』）。さらに、マーケティング部門は「明日から新しい属性を追加してキャンペーンを打ちたい」と急に言ってくる。
もしこれを通常のテーブル設計にしていたら、毎回マイグレーションを流して、カラムを追加して、リリース作業をして……と、ビジネスのスピードに追いつけず、とっくに競合に負けていたはずだ。
② アプリケーション層で「型」と「バリデーション」を担保している
お前さんは「DBに型制約がないから危険だ」と言うけれど、既存システムはアプリケーション側のORM（オブジェクト関係マッピング）やバリデータが、DBに入る前にガチガチにデータの整合性をチェックしている。
DBをただの「超柔軟な永続化ストレージ」と割り切り、ロジックをコード側に集中させることで、むしろスキーマの呪縛から解放された開発スピードを実現しているんだ。
２．なぜ「EAVでOK（むしろこれがベスト）」と言い切れるのか？
お前さんはリプレイスでこれを「きれいなRDBの形」に直したいようだけど、本当にそのメリットはあるかい？擁護派として、EAVを維持すべき3つの理由を挙げる。
理由①：JSON型への移行は「ただの逃げ」であり、パフォーマンスは改善しない
「JSON型（JSONB）にすれば解決」ってよく言われるけど、実態はEAVと何も変わらない。
JSONの中身をインデックス化したり、特定のキーで検索したりするクエリは、結局RDBのオプティマイザにとって不自然な挙動になり、実行計画が狂いやすい。EAVなら、少なくとも「インデックスが貼られた3つのカラム（Entity, Attribute, Value）」という、枯れ果てたシンプルなB-Treeインデックスだけで動いている。下手にJSON型をこねくり回すより、今の単純なEAVの方がはるかにクエリの挙動が予測しやすいんだ。
理由②：テーブル分割（クラス継承設計）は運用保守の地獄を招く
「商品」「アパレル商品」「家電商品」とテーブルを分ける設計（具象テーブル継承など）にしたらどうなる？
新しいジャンルが増えるたびに、新テーブルを作成して、ビューを更新して、プログラムのクラス定義を増やさなきゃいけない。開発の心理的ハードルは爆上がりし、DBのER図はスパゲッティ化する。EAVなら、管理画面からポチポチと「属性を追加」するだけで、開発者の手を一切煩わせずに運用が回るんだ。
理由③：このデータ構造に最適化された「秘伝のクエリソース」がある
「JOIN地獄」と言うけれど、このシステムが長年かけてチューニングしてきたSQLやインデックス、キャッシュ戦略を甘く見ないでほしい。
たしかにクエリは複雑だが、すでにインデックス設計は最適化されており、必要なデータはキャッシュ層（Redis）に逃がす設計になっている。これを下手に「きれいな設計」にリプレイスした結果、未知のボトルネックが発生してシステムが止まるリスクの方が、よっぽどビジネスにとっての害悪じゃないか？
結論：動いている頑丈な城（EAV）を、見た目の美しさだけで壊すな
お前さんの「きれいに整えたい」というエンジニアの美学はリスペクトする。
でも、「ビジネスの変更スピード＞＞＞データの学術的な美しさ」というフェーズにおいて、EAVは間違いなく最強の武器だったし、今も機能している。
このシステムリプレイス、単にお前さんの「教科書通りの美しい設計にしたい欲」を満たすためだけに、この圧倒的な柔軟性を捨てて開発スピードを落とす覚悟はあるかい？
……さあ、批判者としての意見を聞かせてくれよ。
●チャッピーの回答
よろしい。
では、私は「既存システムの設計者・運用責任者」という立場で、EAV(Entity-Attribute-Value)を擁護する。
まず、現状を説明します。
このシステムでは、商品や契約、申込情報など、業務ごとに保持すべき項目が頻繁に変わります。
例えば、
顧客には「法人番号」が追加された
来月から「マイナンバー確認日」が必要
特定商品のみ「保管温度」が必要
来年には法改正で新しい属性が追加される
という変更が毎年発生しています。
このたびに
ALTER TABLE customer ADD COLUMN ...
を実施すると、
DB変更
ORM修正
API修正
バッチ修正
テスト
本番リリース
という一連の作業が必要になります。
我々は、この変更コストを避けるためEAVを採用しました。
メリット1：項目追加がDB変更不要
新しい項目は
attribute_master
id
name
datatype
へ追加するだけ。
データは
customer_value
customer_id
attribute_id
value
へ入ります。
つまり
運用だけで新項目が追加できる。
メリット2：業務部門が自由に項目追加できる
例えば営業から
この商品だけ管理番号増やして
と言われても、
マスタ追加だけで終わります。
開発案件になりません。
メリット3：項目数が読めない
昔は100項目だったものが
今は400項目あります。
普通のテーブルなら
customer
col1
col2
...
col400
になります。
NULLだらけになります。
EAVなら必要なものだけ保持します。
メリット4：製品として販売している
うちのシステムは複数企業へ導入されています。
A社
社員番号
B社
店舗コード
C社
船便番号
全部違います。
毎社ごとにALTER TABLEなんてできません。
EAVなら設定だけで済みます。
メリット5：昔はJSONなんて無かった
設計したのは15年前です。
当時は
JSON型
Generated Column
GIN Index
そんな便利機能ありません。
柔軟性を得る方法としてEAVは普通の選択でした。
「検索が遅い」という批判について
確かに
身長 > 170
みたいな検索はJOINが増えます。
しかし実際には
検索条件は
名前
会員番号
契約番号
など固定項目がほとんどです。
EAV部分は表示用途です。
つまりボトルネックではありません。
「SQLが複雑」という批判
SQLは開発者が書きます。
業務担当者は書きません。
複雑さはアプリケーション側で吸収しています。
だから問題ありません。
「整合性が取れない」
属性マスタで
型
必須
最大長
正規表現
まで管理しています。
入力時にバリデーションしています。
DB制約だけが整合性ではありません。
「EAVはアンチパターン」
よく言われます。
しかし
EAVがアンチパターンなのではありません。
何でもEAVにすることがアンチパターンです。
固定項目までEAVにすると地獄になります。
我々は
顧客番号
氏名
住所
などは普通の列。
変わる部分だけEAVです。
「リプレイスで普通のテーブルへ戻そう」
本当に戻せますか？
現時点で属性は
432種類
あります。
そのうち
A社だけ使う
B社だけ使う
廃止済み
将来使う
が混在しています。
普通のテーブルへすると
customer
......
attribute001
attribute002
attribute003
...
attribute432
になります。
しかも半年後には433になります。
そのたびにリリースです。
最後に
EAVは「理論的に美しい」設計ではありません。
しかし、
項目追加が頻繁
顧客ごとに項目が違う
カスタマイズ性が重要
スキーマ変更コストが高い
という業務要件に対しては、実務上かなり合理的な選択です。
…さて、ここからは逆にリプレイス担当であるあなたが突っ込みそうな点も見えています。
おそらく最初に来るのは、
「その"柔軟性"のために、検索・集計・保守・性能・型安全性・開発効率を全部犠牲にしてませんか？」
という反論でしょう。
この議論は実際によくある構図で、EAV擁護派と批判派それぞれに一理あります。条件次第では、どちらの主張にも十分な根拠があります。
#2
68userさん
ありがとうございます！
とても勉強になります。
確かに、この方法なら単に現場で起こりがちな問題だけではなく、トレードオフも含めてどう対処すべきか、また関係者にどう説明すべきかなど、実践的な学びができそうです。活用させていただきます！
#3
総合スコア56
投稿2026/07/14 05:39
編集2026/07/14 05:42以前、テーブルの全カラムを含む複合インデックスが張られているのを見たことがあります。「インデックスを張れば速くなる」という理解だけで設計された結果だと思われます。
影響としては以下のようなものがありました。
- INSERT/UPDATEのたびに巨大なインデックスの更新が走り、書き込みが遅い
- インデックスサイズがテーブル本体並みに膨らみ、ストレージとメモリを圧迫
- 肝心の検索では先頭カラムが検索条件に合っておらず、ほぼ使われていない(遅くする効果だけ発揮)
ご質問の「気をつけていれば避けられるか」については、知識があれば避けられるものがほとんどだと思います。
しかし現実は「引き継いだ時点ですでにそうなっていた」というケースが多いようで、避けられるかより直せるかの勝負になりがちです。
そして一度データが載ったDBの構造変更は、コードの修正よりはるかに大変です。
#4
ありがとうございます！
実際にインデックスを張りすぎて更新が遅くなることはあるのですね。
直すところに関しては個人の技術もありますが組織として意思決定をとっていく必要がありそうですね…！
あなたの回答
tips
プレビュー