アカウント名:
パスワード:
自分が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設計ミスってない限りは性能出せるはず。
9ぐらいから、サポート対象外ですよね。ところが11でもRBO使ってる人がいてですね…(同じお客さんに入れてる他社の人と雑談してたらそう聞いてびっくり)
ググってみたらホントに使えるらしいんですよ、これが。http://iggyfernandez.wordpress.com/2011/09/21/rule-based-optimizer-in-... [wordpress.com]
これに一票。○○を学ぶには?ってスレがときどき立つけど、必要なら自然に覚えるし、そうでなきゃそんな奴はどうにでもなればいいと思う。
自分は中途半端にDB絡みのプロジェクトに関わって、中途半端に設計やらSQLやらチューニングやら手伝っていて、素人臭いモノを作るのに支障はないけどにわか知識止まりっていうあんま良くない状態で。
もとストーリーの人もこれに近い感覚なんじゃないかな。実践もいいけど、理論に基づいた正しい設計を学ぶ必要性を感じているのでは。
ちゃんとした知識が身に付いていない!勉強しなきゃ!って考えの人に、知識が身に付いていないのって無能なんじゃない?とコメントを付けるのは、罵倒以外の意味がないんだよなあ…。それが分かっているから勉強しようと思っているのに。
それは考え方が極端すぎる。
それだけだと必要だと思い込んでいるいる部分に偏って、とりあえず動くものが作れるようにはなるけれども、本当は必要だけど軽視されがちな大切なことを見逃していたりしやすいので、別途網羅的に学習する必要があると思います。
激しく同意。
「動けば良い」の人だと、インデックスの存在もNOT NULL制約もデフォルト値さえも知らない糞DBエンジニアになったりする。それでも動くことは動くんだよね、小さな糞Webアプリくらいなら。
つかもうぜ!DB!
#でえじょうぶだ、なんとかなる
世界でいっとー手ごわいんですね。
頭空っぽの方が、(スーパーDBエンジニアになれる)夢を詰め込めるんですね、わかります。
データ空っぽなほど夢詰め込めるんで、TRUNCATEなどはいかがでしょうか
同じく……会社入る前は絶対DBだけは携わりたくないと思ってたのに今はバリバリ使わされてる
バッドノウハウなんじゃないかと思いながらもチューニングでいじる部分のうち半分位はDBアクセスに関する部分だから悲しい。
逆にプログラムのプの字も知らないSIにSQLの重要さを理解させるのってかなり大変なんよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア: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でいうなら、結合で簡単に処理できるのにサブクエリを使ってるとか、無駄にUNIONを繰り返してるとか、
そういう「結果は同じだけどパフォーマンスの悪いSQL文」というのはいくらでも存在します。
で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。
#まあ、「実践を通して学習」することの問題は、DBに限った話ではないでしょう。
#プログラミングを実践を通して学習したような人は「計算量」というものについて理解できていない場合が多いと思う。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
>元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。
それ超初心者の話だし。
逆にいうと、DBの世界では注意すべき点が「片手で数えられるくらい」でしかないってことでもある。
そんなのは教えれば教えられる程度。
プログラミングの場合は「数え切れないくらい」にある。
>で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。
そこはプログラミングでも一緒。
DBの方が難しいわけじゃない。
むしろプログラミングの方が問題を認識するテクニックを習得するのが格段に難しい。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:2)
おお、すごい。それはぜひここに書いてほしいですね。きっと参考になる人も多いでしょうし、日本のIT産業のレベルの底上げという意味でも大変有意義だと思います。
私も知りたいです。ぜひぜひ。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
あと、ちゃんとANALYZEして統計情報を作っておくってのも、当たり前だけど大事だよね。
性能でないっていうので見に行くと、こういう基本的な(インデックス作るよりもさらに前の)とこで
ミスってることがある。
それから、1990年代に現役でその後知識更新してない、Rule-based Optimizer 派の言うことは
聞いちゃダメ。あれこそバッドノウハウ。今は Cost-based Optimizer 使って、適宜インデックス
張れば、よほどDB設計ミスってない限りは性能出せるはず。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
9ぐらいから、サポート対象外ですよね。
ところが11でもRBO使ってる人がいてですね…
(同じお客さんに入れてる他社の人と雑談してたらそう聞いてびっくり)
ググってみたらホントに使えるらしいんですよ、これが。
http://iggyfernandez.wordpress.com/2011/09/21/rule-based-optimizer-in-... [wordpress.com]
Re: (スコア:0)
これに一票。
○○を学ぶには?ってスレがときどき立つけど、必要なら自然に覚えるし、そうでなきゃそんな奴はどうにでもなればいいと思う。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:2, 興味深い)
自分は中途半端にDB絡みのプロジェクトに関わって、中途半端に設計やらSQLやらチューニングやら手伝っていて、
素人臭いモノを作るのに支障はないけどにわか知識止まりっていうあんま良くない状態で。
もとストーリーの人もこれに近い感覚なんじゃないかな。実践もいいけど、理論に基づいた正しい設計を学ぶ必要性を感じているのでは。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
ちゃんとした知識が身に付いていない!勉強しなきゃ!って考えの人に、
知識が身に付いていないのって無能なんじゃない?とコメントを付けるのは、
罵倒以外の意味がないんだよなあ…。それが分かっているから勉強しようと思っているのに。
Re: (スコア:0)
それは考え方が極端すぎる。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
それだけだと必要だと思い込んでいるいる部分に偏って、とりあえず動くものが作れるようにはなるけれども、本当は必要だけど軽視されがちな大切なことを見逃していたりしやすいので、別途網羅的に学習する必要があると思います。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
激しく同意。
「動けば良い」の人だと、インデックスの存在もNOT NULL制約もデフォルト値さえも知らない
糞DBエンジニアになったりする。それでも動くことは動くんだよね、小さな糞Webアプリくらいなら。
Re: (スコア:0)
つかもうぜ!DB!
#でえじょうぶだ、なんとかなる
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
世界でいっとー手ごわいんですね。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
頭空っぽの方が、(スーパーDBエンジニアになれる)夢を詰め込めるんですね、わかります。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
データ空っぽなほど夢詰め込めるんで、TRUNCATEなどはいかがでしょうか
Re: (スコア:0)
同じく……会社入る前は絶対DBだけは携わりたくないと思ってたのに
今はバリバリ使わされてる
バッドノウハウなんじゃないかと思いながらも
チューニングでいじる部分のうち半分位はDBアクセスに関する部分だから悲しい。
Re: (スコア:0)
逆にプログラムのプの字も知らないSIにSQLの重要さを理解させるのってかなり大変なんよね。