アカウント名:
パスワード:
自分がDBをを理解したのは「ねえ○○、明日の朝までにこの設計書(という名の要件定義書)通りにDAO作っといてもらえる?」の一言がきっかけでした。あとはまあ、実践を通して徐々に。
データベースの難しいところは、「要件定義を満たすDB設計・問い合わせSQL」であっても、ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。
DB設計で言うと、正規化されてなかったり横展開されてたりとかですね。こっちはまあ、教科書的に学習するのは難しくないですが、最初の設計が腐ってたら後から修正するのは困難なので「実践を通して徐々に」なてやってほしくない。
一方SQLの方は、まあ後から修正するが容易なのでまだマシですが…
普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、SQLの場合、同じSQL文でもDB定義(インデックス)次第で線形探索になったりn分探索になったりする。動作としては問題ないから「実践を通して」なんてやってたりすると、いつまで経っても問題に気づけないでしょう。
SQL文を組み立てたときは、とりあえずEXPLAINで確認かな。
>データベースの難しいところは、>「要件定義を満たすDB設計・問い合わせSQL」であっても、>ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。むしろそれはDBの「簡単な所」だと思う。パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せるんだから。
プログラムでパフォーマンス問題が出た時は、んな簡単には直せない。データ構造とアルゴリズムを見直し、コード全部を書き直す必要に迫られることもしばしば。だからプログラムではパフォーマンス問題が出る前に、コードを書く前に事前に問題を潰しておく必要がある。
>普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、
んなのはパフォーマンス以前の問題だと思うなあ。DBでいうならインデックスを「全く」張ってなかったレベル。
そしてソートだけならソートアルゴリズムを入れ替えれば早くなる。大した問題じゃない。
一応まあわかりやすく説明するために、設計の善し悪しの指標としてパフォーマンスを挙げましたけど、それだけの問題じゃないです。
> パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せる
元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。参照だけならビューを作って誤魔化せるけど、更新が絡むと絶対無理が出る。
> ソートだけならソートアルゴリズムを入れ替えれば早くなる。
ソートを挙げたのは、アルゴリズムの善し悪しの例。SQL文の善し悪しの例のつもりではありませんでした。SQL
>元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。それ超初心者の話だし。
逆にいうと、DBの世界では注意すべき点が「片手で数えられるくらい」でしかないってことでもある。そんなのは教えれば教えられる程度。プログラミングの場合は「数え切れないくらい」にある。
>で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。
そこはプログラミングでも一緒。DBの方が難しいわけじゃない。
むしろプログラミングの方が問題を認識するテクニックを習得するのが格段に難しい。
逆にいうと、DBの世界では注意すべき点が「片手で数えられるくらい」でしかないってことでもある。そんなのは教えれば教えられる程度。
おお、すごい。それはぜひここに書いてほしいですね。きっと参考になる人も多いでしょうし、日本のIT産業のレベルの底上げという意味でも大変有意義だと思います。
私も知りたいです。ぜひぜひ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:2)
自分がDBをを理解したのは「ねえ○○、明日の朝までにこの設計書(という名の要件定義書)通りにDAO作っといてもらえる?」の一言がきっかけでした。
あとはまあ、実践を通して徐々に。
Re: (スコア:1)
データベースの難しいところは、
「要件定義を満たすDB設計・問い合わせSQL」であっても、
ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。
DB設計で言うと、正規化されてなかったり横展開されてたりとかですね。
こっちはまあ、教科書的に学習するのは難しくないですが、
最初の設計が腐ってたら後から修正するのは困難なので「実践を通して徐々に」なてやってほしくない。
一方SQLの方は、まあ後から修正するが容易なのでまだマシですが…
普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、
SQLの場合、同じSQL文でもDB定義(インデックス)次第で線形探索になったりn分探索になったりする。
動作としては問題ないから「実践を通して」なんてやってたりすると、いつまで経っても問題に気づけないでしょう。
SQL文を組み立てたときは、とりあえずEXPLAINで確認かな。
Re: (スコア:2)
>データベースの難しいところは、
>「要件定義を満たすDB設計・問い合わせSQL」であっても、
>ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。
むしろそれはDBの「簡単な所」だと思う。
パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せるんだから。
プログラムでパフォーマンス問題が出た時は、んな簡単には直せない。
データ構造とアルゴリズムを見直し、コード全部を書き直す必要に迫られることもしばしば。
だからプログラムではパフォーマンス問題が出る前に、コードを書く前に事前に問題を
潰しておく必要がある。
>普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、
んなのはパフォーマンス以前の問題だと思うなあ。
DBでいうならインデックスを「全く」張ってなかったレベル。
そしてソートだけならソートアルゴリズムを入れ替えれば早くなる。
大した問題じゃない。
Re: (スコア:2)
一応まあわかりやすく説明するために、設計の善し悪しの指標としてパフォーマンスを挙げましたけど、それだけの問題じゃないです。
> パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せる
元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。
参照だけならビューを作って誤魔化せるけど、更新が絡むと絶対無理が出る。
> ソートだけならソートアルゴリズムを入れ替えれば早くなる。
ソートを挙げたのは、アルゴリズムの善し悪しの例。SQL文の善し悪しの例のつもりではありませんでした。
SQL
Re: (スコア:1)
>元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。
それ超初心者の話だし。
逆にいうと、DBの世界では注意すべき点が「片手で数えられるくらい」でしかないってことでもある。
そんなのは教えれば教えられる程度。
プログラミングの場合は「数え切れないくらい」にある。
>で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。
そこはプログラミングでも一緒。
DBの方が難しいわけじゃない。
むしろプログラミングの方が問題を認識するテクニックを習得するのが格段に難しい。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:2)
おお、すごい。それはぜひここに書いてほしいですね。きっと参考になる人も多いでしょうし、日本のIT産業のレベルの底上げという意味でも大変有意義だと思います。
私も知りたいです。ぜひぜひ。