パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

/.Jに聞け:SQL/DBの正しい学び方は?」記事へのコメント

  • 自分がDBをを理解したのは「ねえ○○、明日の朝までにこの設計書(という名の要件定義書)通りにDAO作っといてもらえる?」の一言がきっかけでした。
    あとはまあ、実践を通して徐々に。

    • データベースの難しいところは、
      「要件定義を満たすDB設計・問い合わせSQL」であっても、
      ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。

      DB設計で言うと、正規化されてなかったり横展開されてたりとかですね。
      こっちはまあ、教科書的に学習するのは難しくないですが、
      最初の設計が腐ってたら後から修正するのは困難なので「実践を通して徐々に」なてやってほしくない。

      一方SQLの方は、まあ後から修正するが容易なのでまだマシですが…

      普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、
      SQLの場合、同じSQL文でもDB定義(インデックス)次第で線形探索になったりn分探索になったりする。
      動作としては問題ないから「実践を通して」なんてやってたりすると、いつまで経っても問題に気づけないでしょう。

      SQL文を組み立てたときは、とりあえずEXPLAINで確認かな。

      親コメント
      • >データベースの難しいところは、
        >「要件定義を満たすDB設計・問い合わせSQL」であっても、
        >ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。
        むしろそれはDBの「簡単な所」だと思う。
        パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せるんだから。

        プログラムでパフォーマンス問題が出た時は、んな簡単には直せない。
        データ構造とアルゴリズムを見直し、コード全部を書き直す必要に迫られることもしばしば。
        だからプログラムではパフォーマンス問題が出る前に、コードを書く前に事前に問題を
        潰しておく必要がある。

        >普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、

        んなのはパフォーマンス以前の問題だと思うなあ。
        DBでいうならインデックスを「全く」張ってなかったレベル。

        そしてソートだけならソートアルゴリズムを入れ替えれば早くなる。
        大した問題じゃない。

        親コメント
        • 一応まあわかりやすく説明するために、設計の善し悪しの指標としてパフォーマンスを挙げましたけど、それだけの問題じゃないです。

          > パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せる

          元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。
          参照だけならビューを作って誤魔化せるけど、更新が絡むと絶対無理が出る。

          > ソートだけならソートアルゴリズムを入れ替えれば早くなる。

          ソートを挙げたのは、アルゴリズムの善し悪しの例。SQL文の善し悪しの例のつもりではありませんでした。
          SQLでいうなら、結合で簡単に処理できるのにサブクエリを使ってるとか、無駄にUNIONを繰り返してるとか、
          そういう「結果は同じだけどパフォーマンスの悪いSQL文」というのはいくらでも存在します。

          で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。

          #まあ、「実践を通して学習」することの問題は、DBに限った話ではないでしょう。
          #プログラミングを実践を通して学習したような人は「計算量」というものについて理解できていない場合が多いと思う。

          親コメント
          • >元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。
            それ超初心者の話だし。

            逆にいうと、DBの世界では注意すべき点が「片手で数えられるくらい」でしかないってことでもある。
            そんなのは教えれば教えられる程度。
            プログラミングの場合は「数え切れないくらい」にある。

            >で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。

            そこはプログラミングでも一緒。
            DBの方が難しいわけじゃない。

            むしろプログラミングの方が問題を認識するテクニックを習得するのが格段に難しい。

            親コメント
            • 逆にいうと、DBの世界では注意すべき点が「片手で数えられるくらい」でしかないってことでもある。
              そんなのは教えれば教えられる程度。

              おお、すごい。それはぜひここに書いてほしいですね。きっと参考になる人も多いでしょうし、日本のIT産業のレベルの底上げという意味でも大変有意義だと思います。

              私も知りたいです。ぜひぜひ。

              親コメント
      • あと、ちゃんとANALYZEして統計情報を作っておくってのも、当たり前だけど大事だよね。
        性能でないっていうので見に行くと、こういう基本的な(インデックス作るよりもさらに前の)とこで
        ミスってることがある。

        それから、1990年代に現役でその後知識更新してない、Rule-based Optimizer 派の言うことは
        聞いちゃダメ。あれこそバッドノウハウ。今は Cost-based Optimizer 使って、適宜インデックス
        張れば、よほどDB設計ミスってない限りは性能出せるはず。

        親コメント

計算機科学者とは、壊れていないものを修理する人々のことである

処理中...