/.Jに聞け：SQL/DBの正しい学び方は？ 54
ストーリー by hylom
Wikipediaで調べる（真顔） 部門より
Wikipediaで調べる（真顔） 部門より
あるAnonymous Coward 曰く、
本家/.「Ask Slashdot: Learning DB the Right Way; Books, Tutorials, or What?」より。
技術畑の人間が新たにPostgreSQLでSQL/DBを学ぶのに最良の方法は本だろうか、それともチュートリアルだろうか？もしくはそれよりも良い策が他にあるだろうか。
今までは他の人の書いたコードを読んだり、実際にいろいろ試したり、PostgreSQLドキュメントに目を通したりして学んできた。その甲斐もあってかDBを理解してきたが、まだ多くのことを知らないし間違って身に付いていることもあるだろう。その証拠にスラドでDBのストーリーを読むと初めて目にする用語が結構ある。
なお、自分はプログラミングに関しては複数言語で長年の経験があるが、SQLに関してはPostgreSQLを通じて多少いじった程度である。数学は三角法、代数、少々の統計をかじったバックグラウンドがある。
また、近くに通える大学はなく、DBに詳しい人も周りにいないため独学せざるを得なく、インターネットと本が頼りなのが実情であることを付け加えておきたい。
本家/.ではクリス・デイトが著した「データベースシステム概論」を推す声が多いようだ。/.J諸兄方はどのようにして学んできただろうか？
書籍あれこれ (スコア:5, 参考になる)
入門はこれがいいんじゃないかな
「SQL-ゼロからはじめるデータベース操作」 [amazon.co.jp] ミック
データベース設計の入門はこの辺
「達人に学ぶDB設計 徹底指南書」 [amazon.co.jp] ミック
「楽々ERDレッスン」 [amazon.co.jp] 羽生章洋
他のコメントでも挙がってるけど、以下の本は持ってるべき。でも入門書じゃないね。
「プログラマのためのSQL 第4版」 [amazon.co.jp] Joe Celko
タイトルに反して理想論的な本だけど、以下の本も読んでおくといいと思う。これ絶版なのかあ。
「データベース実践講義 ―エンジニアのためのリレーショナル理論 」 [amazon.co.jp] C.J.Date
Re:書籍あれこれ (スコア:1)
この親コメント、誰かプラスモデレートしてくれるとうれしいなあ。
RDBは集合論と関係モデルをベースにしているので、そこを理解するだけでおおちがい。実践優先だとそこまでたどりつくのはたいへん……
でも単なるストレージ代わりにRDBを使うケースもあって、そういうのにはもうちょっと適切な選択肢があるといいのだけど。
# NoSQLの登場はそういう意味でも朗報。
Re:書籍あれこれ (スコア:2)
これは本当にそう思いますね。
実際、私の知っている開発の範囲で、わざわざ関係データベース使わなくてもいいんじゃないか、と思えるケースは多いのですが、やはり揃っている機能や実績、ノウハウの豊富さで RDBMS を選択することがほとんどです。
近年はようやく状況が変わりつつあるようですが。
Re: (スコア:0)
ODBは駄目ですかそうですか
Re: (スコア:0)
タイトルに反して理想論的な本だけど、以下の本も読んでおくといいと思う。これ絶版なのかあ。
「データベース実践講義 ―エンジニアのためのリレーショナル理論 」 [amazon.co.jp] C.J.Date
O'Reilly Ebook Storeで買えるようです
http://www.oreilly.co.jp/books/4873112753/ [oreilly.co.jp]
基礎を知らずに設計すると後で大変困ったことになる。それがDB。 (スコア:3, 参考になる)
基礎を勉強するならデータベーススペシャリスト試験の参考書がよくまとまっていて良い。
分厚くて高価な本は枕にしかならない。
# 全て実証済み。
-------- tear straight across --------
まずは問題有りき (スコア:3, 参考になる)
ああ、参考書は使えそうだね。
でも、その前に、過去問なり、予想問題集なりの「問題文『だけ』」を入手して解くのが先かな？
こっちなら、小一時間で済む。
で、回答出来なかった問題を参考書を見ながら解いて、知識を補充。
そして、「謎の用語」に出会った所で、その用語を詳しく説明する専門書の順序なら、積まれ難い。
でも、ぶっちゃけ、「DB設計に正解は無い」んだよね。
一番重要なのは「何処で折り合いを付けるか」で、これは数こなす以外に身に付かない。
更に、DB設計だと、対象の業務知識と、下位のプログラム設計レベルでの知識の両方を持って無いと適切な設計が出来ない。出来れば運用レベルの知識も欲しい。
更に更に、必要なデータや処理するAPIなんかがコロコロ変わるから、常に最新情報を追いかけないと、ポンコツ人間しか残らない。
こんなのを網羅する「教科書なんて実在しない」が真の答えじゃないかな？
-- Buy It When You Found It --
Re:基礎を知らずに設計すると後で大変困ったことになる。それがDB。 (スコア:1)
まずはSQLから離れてデータベースの(データ構造)を勉強するべき。
きちんと設計されたDBならSQLなんてどうにでもなる。
というかクエリーがうまく書けるように設計されてる。
まず、RDBを勉強、設計するツールとしてER図
Re: (スコア:0)
まさにこれ
人に教わろうとする前にまず手と頭を動かせと言いたいね。DBに限った話じゃないが
Re: (スコア:0)
そう言われると確かに、独学ではこれがお勧めできると思えた。
もちろん、デキる師匠がいてくれたら良いんだけど。
DB個別のチューンに関してはそれぞれの専門書を当たらなければならないけれど、
DBについての基礎力自体はこの方法が良さそう。
午前の範囲に関しては問題が解けるようになる必要はないと思うけれど、
午後問題はちゃんと頭を悩ませてみた方が良い。むしろ午後問題が肝。
DBって、特に勉強なしに使ってみても使えるけど、
「独学でとりあえず使ってみる」では、気付けない部分が出てくるんだよね。
ちょっとしたWebアプリなどはそれでも問題なかったりするから、歪な知識になりがち。
DBを学びたい、という目的ではちょっとお勧めできない。
Re: (スコア:0)
え〜、データベーススペシャリスト試験の参考書って枕にちょうどいいのに。
アプリを作ってみる (スコア:2, 参考になる)
Web App を作ってみるのを勧めます。
友人たちにつかってもらいながら、少しずつ機能を追加したり、不具合を直していくと実践的な勉強にもになるしね。
使ってもらいやすいように、みんなの自己紹介を掲載して、友人同士で紹介しあうサービスなんかいいんじゃないかな？
Re: (スコア:0)
Web Appだと単なる Data Storeにしか使わない例も多いからRDBを深く学びたい人には役に立たないだろ。
そもそも、アプリを作ってみて壁に当たった人にアプリを作ってみろって助言になってないよ。
SQL for Smarties (スコア:2, 参考になる)
プログラマのためのSQL [amazon.co.jp]は持っておくべき。
ただし入門書ではないので、これ一つだけでものにするのは難しい。
Re:SQL for Smarties (スコア:2)
# 版を重ねるごとに厚みが増していくのが難点
プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:2)
自分がDBをを理解したのは「ねえ○○、明日の朝までにこの設計書(という名の要件定義書)通りにDAO作っといてもらえる？」の一言がきっかけでした。
あとはまあ、実践を通して徐々に。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
データベースの難しいところは、
「要件定義を満たすDB設計・問い合わせSQL」であっても、
ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。
DB設計で言うと、正規化されてなかったり横展開されてたりとかですね。
こっちはまあ、教科書的に学習するのは難しくないですが、
最初の設計が腐ってたら後から修正するのは困難なので「実践を通して徐々に」なてやってほしくない。
一方SQLの方は、まあ後から修正するが容易なのでまだマシですが…
普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、
SQLの場合、同じSQL文でもDB定義(インデックス)次第で線形探索になったりn分探索になったりする。
動作としては問題ないから「実践を通して」なんてやってたりすると、いつまで経っても問題に気づけないでしょう。
SQL文を組み立てたときは、とりあえずEXPLAINで確認かな。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:2)
＞データベースの難しいところは、
＞「要件定義を満たすDB設計・問い合わせSQL」であっても、
＞ちょっとした違いでパフォーマンスが大きく違うってところにあると思う。
むしろそれはＤＢの「簡単な所」だと思う。
パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せるんだから。
プログラムでパフォーマンス問題が出た時は、んな簡単には直せない。
データ構造とアルゴリズムを見直し、コード全部を書き直す必要に迫られることもしばしば。
だからプログラムではパフォーマンス問題が出る前に、コードを書く前に事前に問題を
潰しておく必要がある。
＞普通のプログラミング言語を使っていて、線形探索だのバブルソートだのを使ってたら、見る者が見ればすぐに気づくけど、
んなのはパフォーマンス以前の問題だと思うなあ。
ＤＢでいうならインデックスを「全く」張ってなかったレベル。
そしてソートだけならソートアルゴリズムを入れ替えれば早くなる。
大した問題じゃない。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:2)
一応まあわかりやすく説明するために、設計の善し悪しの指標としてパフォーマンスを挙げましたけど、それだけの問題じゃないです。
> パフォーマンスが悪くても、そこの部分だけをちょっと修正すれば直せる
元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。
参照だけならビューを作って誤魔化せるけど、更新が絡むと絶対無理が出る。
> ソートだけならソートアルゴリズムを入れ替えれば早くなる。
ソートを挙げたのは、アルゴリズムの善し悪しの例。SQL文の善し悪しの例のつもりではありませんでした。
SQLでいうなら、結合で簡単に処理できるのにサブクエリを使ってるとか、無駄にUNIONを繰り返してるとか、
そういう「結果は同じだけどパフォーマンスの悪いSQL文」というのはいくらでも存在します。
で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。
#まあ、「実践を通して学習」することの問題は、DBに限った話ではないでしょう。
#プログラミングを実践を通して学習したような人は「計算量」というものについて理解できていない場合が多いと思う。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
＞元コメで挙げた「正規化されてなかったり横展開されてたり」なんてレベルだと、「ちょっと修正」なんてむりでしょう。
それ超初心者の話だし。
逆にいうと、ＤＢの世界では注意すべき点が「片手で数えられるくらい」でしかないってことでもある。
そんなのは教えれば教えられる程度。
プログラミングの場合は「数え切れないくらい」にある。
＞で、一番の問題は、たとえ「ちょっと修正すれば直せる」ものだとしても、そもそも「実践を通して学習」しているような人は、「修正すべき」であることすら認識できない、ってことでしょう。
そこはプログラミングでも一緒。
ＤＢの方が難しいわけじゃない。
むしろプログラミングの方が問題を認識するテクニックを習得するのが格段に難しい。
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)
激しく同意。
「動けば良い」の人だと、インデックスの存在もＮＯＴ ＮＵＬＬ制約もデフォルト値さえも知らない
糞ＤＢエンジニアになったりする。それでも動くことは動くんだよね、小さな糞Ｗｅｂアプリくらいなら。
Re: (スコア:0)
つかもうぜ！DB！
#でえじょうぶだ、なんとかなる
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
世界でいっとー手ごわいんですね。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
頭空っぽの方が、（スーパーＤＢエンジニアになれる）夢を詰め込めるんですね、わかります。
Re:プログラマーは栄養ドリンク飲ませときゃ育つので楽 (スコア:1)
データ空っぽなほど夢詰め込めるんで､TRUNCATEなどはいかがでしょうか
Re: (スコア:0)
同じく……会社入る前は絶対DBだけは携わりたくないと思ってたのに
今はバリバリ使わされてる
バッドノウハウなんじゃないかと思いながらも
チューニングでいじる部分のうち半分位はDBアクセスに関する部分だから悲しい。
Re: (スコア:0)
逆にプログラムのプの字も知らないSIにSQLの重要さを理解させるのってかなり大変なんよね。
それでもよい教師を探せという (スコア:2)
タレコミ内容無視するけど、独学はやっぱり限界がある。
Re: (スコア:0)
よい教師をどう探すのかまったく想像がつかない。
Re:それでもよい教師を探せという (スコア:1)
from IT業界
where 評判 = よい
order by 経験値 desc
Re:それでもよい教師を探せという (スコア:2)
レコードが選択されませんでした。
Re:それでもよい教師を探せという (スコア:1)
----------
google
1件選択されました
# yes, fly. no, fry.
MS Access (スコア:2)
僕は MS Access から RDB に入ったのだが、
MS Access の場合、GUI でクエリを作成するツールがあり、これが意外に「テーブル」や「JOIN」に対する直観を養うのに有効だった。
ほかの DB でも GUIツールはあるのだが、Access みたいに GUIツールの方が前面には来ていないようだし。
マクロの基本は検索置換(by y.mikome)
scott/tiger EMP表 (スコア:2)
T/O
＃つーか、若い人はンなこと言われても知らないか…(^^;
参考文献や講習の多いDBMSを学ぶ (スコア:1)
まとまった知識が欲しいなら、「参考文献や講習の多いDBMSを学ぶ」のが良いです。目的のDBMSは、その次に。
# 日本だとoracleが一番参考書多いのかしら？
notice : I ignore an anonymous contribution.
Re:参考文献や講習の多いDBMSを学ぶ (スコア:2)
会社から Oracle Bronze 資格取れと言われて参考書を勉強したら、
基礎から実践までひと通り理解できました。SQLの解説書を参考にしながら
プログラミングしていた頃に比べれば、だいぶ進歩。
まあベンダ資格なので、SQLが標準と違うとか、多少の欠点はあります。
Re:参考文献や講習の多いDBMSを学ぶ (スコア:1)
同じ会社が作ってるはずなのにOracleとMySQLになると最適化の方法が全然違うけどな。
Ver 5.5で改善されたけどサブクエリーでインデックスが使えないとかな。サブクエリーからは数個に絞れるはずなのにインデックスが使えないからとんでもなく遅くなる。仕方ないんでクエリーを分けて実行とかしないといけないとかいうバッドノウハウはどう身に着けますか？
何が「正しい」のか (スコア:1)
＃手っ取り早いのは実地だけど、運の要素が強すぎる
作って学んだ (スコア:0)
自分で作った。卒論で教官が無茶振りしてくれたおかげ。
トランザクションも何も無しで、create table, insert, update, delete, selectだけだったかな。
なぜかraw deviceを使っていたので、その辺りのいじり方を覚えたのが収穫だった。
自分の場合 (スコア:0)
もう十数年以上前になるが、丸山不二夫先生の「UNIX データベース入門 [wakhok.ac.jp]」で SQL の基本を学びながら PostgreSQL をいじりはじめた。
コンパクトな内容だが、後半では「 データベースの論理設計」等にもきちんと触れられているのでオススメ。
多分、大学に通っても授業レベルだとこれ以上の内容は望めないと思う。
セキュリティ対策関連の内容には触れられてないため、IPA の「安全なウェブサイトの作り方 [ipa.go.jp]」の別冊である「安全なSQLの呼び出し方」 を併読すると良いと思う。
何になりたいかによる (スコア:0)
エンドユーザかプログラマーか設計者か管理者かで違うと思う。
エンドユーザならSQLとDBの概念がわかってればいい。
プログラマーならトランザクションの知識とDBで使われるアルゴリズムの知識。
管理者は使用するDBMS毎の知識。
設計者は正規化と上記全部を広く浅く。