レバテック開発部Publication Pro🔨スキーマを放棄したデータベース設計 - 『SQLアンチパターン』のEAVについて考察するもりた2024/02/15に公開3件SQLDBtechレバテック開発部Publication Proレバテック開発部の公式テックブログです！Discussiontez2024/10/14 クエリが冗長で複雑 EAVのデメリットとしてよく言われていますが、冗長ではなく単に「文字数が多い」だけなのでは？ 必要な記述は多少長かろうが無駄ではないので、決して「冗長」ではないと思います。 WHERE句に条件が増えるのも特別なテクニックが必要な訳ではなく、シンプルな条件の列記が増えるだけだと思うけれど、長いSQLは全て複雑ですか？ もりた2024/10/16コメントありがとうございます！ ちょっともりたがアホなので論点を整理させてもらうと、 論点整理 tezさん意見 EAVのデメリットとして冗長かつ複雑（無駄に文字数が多い）が挙げられている が、実態として必要な記述であれば無駄ではなく、文字数が多くても冗長ではないのでは 論点 （通常のテーブル構成なら不必要だった、）EAVでは必要な記述に手間暇かける価値あるかどうか なので、いま喋った方がいいのは以下の２点だと思います。 ①通常のテーブル構成と比較して冗長・複雑であるか ②そういう記述に手間暇かける価値があるか ①通常のテーブル構成と比較して冗長・複雑であるか そういう意味ですと、 長いSQLは全て複雑ですか？ 長いSQLは、同じデータ操作を目的とするより短いSQLと比較して複雑であり、冗長だろうなと思います。 （自己相関するクエリは短いけど複雑じゃんとかは今回の論点から外れるので考慮しないこととしてます） ②そういう記述に手間暇かける価値があるか これはケースバイケースだと思います。EAVが生きるケースは記事の中にも挙げてますが、そのケースだったり、他にも気がついていないケースがあるのではないかと思っています。 （なにかそういうケースがあったら教えて欲しいです） 以上です！ この記事の元ネタになってる書籍が記事末尾にあるので、そちらも読まれてはいかがかと思います。おそらくtezさんの疑問に対していろんな観点を与えてくれる記述があるのではないかと思います。 返信を追加tez2024/10/29素早いお返事に対応できなくて申し訳ありませんでした。 僕の個人的な感覚は多くの方に共感していただけないのだろうとは思いますが、長かろうが複雑だろうが、必要であるなら冗長ではないと思うのです。言い換えると、不要なモノを含んでいる場合に「冗長」と呼ぶのだと思うのです。 通常のテーブル構成と比較して 比較する際に、通常のテーブル構成にする為にテーブルやカラムを増やすコストを無視してしまうのは、フェアじゃないなぁと思うのです。（テーブルやカラムが増えれば CREATE TABLE 〜、ALTER TABLE 〜 等を１回実行するだけで済むなんてヌルい事はないですよね？）単純に（アレコレが済んで）取得するSQLが長い（≠冗長）か短いかだけを比較するのは片手落ちなんだろうなとも思うのです。 もちろん最終的な実行時の事だけ比較したいと言うニーズもあるでしょう。（大方の場合がそうであるのかも知れませんが） 成長途中のシステムだと、仕様がドンドン追加変更されるのが常です。 EAVが採用されるべきケースだと思いますので、気にせずに進めれば良いだけなんですけどね。世の中でアンチパターンと呼ぶ理由が何となく薄いなぁと感じたので手近なところで（ごめんなさい🙏）ご意見を聞ければと思って書き込みました。 返信を追加
tez2024/10/14 クエリが冗長で複雑 EAVのデメリットとしてよく言われていますが、冗長ではなく単に「文字数が多い」だけなのでは？ 必要な記述は多少長かろうが無駄ではないので、決して「冗長」ではないと思います。 WHERE句に条件が増えるのも特別なテクニックが必要な訳ではなく、シンプルな条件の列記が増えるだけだと思うけれど、長いSQLは全て複雑ですか？ もりた2024/10/16コメントありがとうございます！ ちょっともりたがアホなので論点を整理させてもらうと、 論点整理 tezさん意見 EAVのデメリットとして冗長かつ複雑（無駄に文字数が多い）が挙げられている が、実態として必要な記述であれば無駄ではなく、文字数が多くても冗長ではないのでは 論点 （通常のテーブル構成なら不必要だった、）EAVでは必要な記述に手間暇かける価値あるかどうか なので、いま喋った方がいいのは以下の２点だと思います。 ①通常のテーブル構成と比較して冗長・複雑であるか ②そういう記述に手間暇かける価値があるか ①通常のテーブル構成と比較して冗長・複雑であるか そういう意味ですと、 長いSQLは全て複雑ですか？ 長いSQLは、同じデータ操作を目的とするより短いSQLと比較して複雑であり、冗長だろうなと思います。 （自己相関するクエリは短いけど複雑じゃんとかは今回の論点から外れるので考慮しないこととしてます） ②そういう記述に手間暇かける価値があるか これはケースバイケースだと思います。EAVが生きるケースは記事の中にも挙げてますが、そのケースだったり、他にも気がついていないケースがあるのではないかと思っています。 （なにかそういうケースがあったら教えて欲しいです） 以上です！ この記事の元ネタになってる書籍が記事末尾にあるので、そちらも読まれてはいかがかと思います。おそらくtezさんの疑問に対していろんな観点を与えてくれる記述があるのではないかと思います。 返信を追加
もりた2024/10/16コメントありがとうございます！ ちょっともりたがアホなので論点を整理させてもらうと、 論点整理 tezさん意見 EAVのデメリットとして冗長かつ複雑（無駄に文字数が多い）が挙げられている が、実態として必要な記述であれば無駄ではなく、文字数が多くても冗長ではないのでは 論点 （通常のテーブル構成なら不必要だった、）EAVでは必要な記述に手間暇かける価値あるかどうか なので、いま喋った方がいいのは以下の２点だと思います。 ①通常のテーブル構成と比較して冗長・複雑であるか ②そういう記述に手間暇かける価値があるか ①通常のテーブル構成と比較して冗長・複雑であるか そういう意味ですと、 長いSQLは全て複雑ですか？ 長いSQLは、同じデータ操作を目的とするより短いSQLと比較して複雑であり、冗長だろうなと思います。 （自己相関するクエリは短いけど複雑じゃんとかは今回の論点から外れるので考慮しないこととしてます） ②そういう記述に手間暇かける価値があるか これはケースバイケースだと思います。EAVが生きるケースは記事の中にも挙げてますが、そのケースだったり、他にも気がついていないケースがあるのではないかと思っています。 （なにかそういうケースがあったら教えて欲しいです） 以上です！ この記事の元ネタになってる書籍が記事末尾にあるので、そちらも読まれてはいかがかと思います。おそらくtezさんの疑問に対していろんな観点を与えてくれる記述があるのではないかと思います。
tez2024/10/29素早いお返事に対応できなくて申し訳ありませんでした。 僕の個人的な感覚は多くの方に共感していただけないのだろうとは思いますが、長かろうが複雑だろうが、必要であるなら冗長ではないと思うのです。言い換えると、不要なモノを含んでいる場合に「冗長」と呼ぶのだと思うのです。 通常のテーブル構成と比較して 比較する際に、通常のテーブル構成にする為にテーブルやカラムを増やすコストを無視してしまうのは、フェアじゃないなぁと思うのです。（テーブルやカラムが増えれば CREATE TABLE 〜、ALTER TABLE 〜 等を１回実行するだけで済むなんてヌルい事はないですよね？）単純に（アレコレが済んで）取得するSQLが長い（≠冗長）か短いかだけを比較するのは片手落ちなんだろうなとも思うのです。 もちろん最終的な実行時の事だけ比較したいと言うニーズもあるでしょう。（大方の場合がそうであるのかも知れませんが） 成長途中のシステムだと、仕様がドンドン追加変更されるのが常です。 EAVが採用されるべきケースだと思いますので、気にせずに進めれば良いだけなんですけどね。世の中でアンチパターンと呼ぶ理由が何となく薄いなぁと感じたので手近なところで（ごめんなさい🙏）ご意見を聞ければと思って書き込みました。 返信を追加
Discussion
EAVのデメリットとしてよく言われていますが、冗長ではなく単に「文字数が多い」だけなのでは？
必要な記述は多少長かろうが無駄ではないので、決して「冗長」ではないと思います。
WHERE句に条件が増えるのも特別なテクニックが必要な訳ではなく、シンプルな条件の列記が増えるだけだと思うけれど、長いSQLは全て複雑ですか？
コメントありがとうございます！
ちょっともりたがアホなので論点を整理させてもらうと、
論点整理
なので、いま喋った方がいいのは以下の２点だと思います。
①通常のテーブル構成と比較して冗長・複雑であるか
そういう意味ですと、
長いSQLは、同じデータ操作を目的とするより短いSQLと比較して複雑であり、冗長だろうなと思います。
（自己相関するクエリは短いけど複雑じゃんとかは今回の論点から外れるので考慮しないこととしてます）
②そういう記述に手間暇かける価値があるか
これはケースバイケースだと思います。EAVが生きるケースは記事の中にも挙げてますが、そのケースだったり、他にも気がついていないケースがあるのではないかと思っています。
（なにかそういうケースがあったら教えて欲しいです）
以上です！
この記事の元ネタになってる書籍が記事末尾にあるので、そちらも読まれてはいかがかと思います。おそらくtezさんの疑問に対していろんな観点を与えてくれる記述があるのではないかと思います。
素早いお返事に対応できなくて申し訳ありませんでした。
僕の個人的な感覚は多くの方に共感していただけないのだろうとは思いますが、長かろうが複雑だろうが、必要であるなら冗長ではないと思うのです。言い換えると、不要なモノを含んでいる場合に「冗長」と呼ぶのだと思うのです。
比較する際に、通常のテーブル構成にする為にテーブルやカラムを増やすコストを無視してしまうのは、フェアじゃないなぁと思うのです。（テーブルやカラムが増えれば CREATE TABLE 〜、ALTER TABLE 〜 等を１回実行するだけで済むなんてヌルい事はないですよね？）単純に（アレコレが済んで）取得するSQLが長い（≠冗長）か短いかだけを比較するのは片手落ちなんだろうなとも思うのです。
もちろん最終的な実行時の事だけ比較したいと言うニーズもあるでしょう。（大方の場合がそうであるのかも知れませんが）
成長途中のシステムだと、仕様がドンドン追加変更されるのが常です。
EAVが採用されるべきケースだと思いますので、気にせずに進めれば良いだけなんですけどね。世の中でアンチパターンと呼ぶ理由が何となく薄いなぁと感じたので手近なところで（ごめんなさい🙏）ご意見を聞ければと思って書き込みました。