昨日の6日目はkaigaiさんの
SE-PostgreSQLでリモートプロセスのセキュリティラベルを使用する
でした。
SELinuxを心を痛めながら殺してしまうこと、皆さんも何度かあるんじゃないでしょうか?
SELinuxを心を痛めながら殺してしまうこと、皆さんも何度かあるんじゃないでしょうか?
と言うわけでここらからが本題。
そしてまず公開遅れてごめんなさい。一度書いたのですがどうしても書き直したくて書き直しちゃいました。
書いたネタはせっかくなので二週目の時に公開しますね。
そしてあんまりPostgreSQLに関係ない話になりそうです、ごめんなさい。
で表題ですが元ネタがあります。
そーだいと言えばすぐORMをdisと言うイメージがあるらしいのですがまず前提として
よく考えられたDB設計で使うORMは凄く便利
ですよ。
ただ現実として後から仕様変更だったり想定外なことだったりで複雑なQueryを求められることがあると思います。
実際に開発時は大半のSQLが単純でORMで取り出すことで簡略化出来ることも多いけどそれが全てでは無いですよね。
ちょっと複雑なQueryをORMで取り出そうとすると急に難しくなり、かと言って問合せ回数を増やすようなプログラムを書くとI/Oやら負荷やらが急に上がって…(´・ω・`)
なのでORMは便利なんだから使えばいいと思いますがベストプラクティスを目指すなら発行されるSQLを理解した上で生SQLとケースバイケース使い分ける必要があります。
まさに@t_wadaさんが素晴らしいことをツイートしてて
こういうことです。
ただORMがSQLのオプティマイザーやプリコンパイラみたいに最適化されたSQLを発行するようになればSQLをあまり意識しないでもいいかもしれません。
しかしそこに現状はまだまだその領域にORMが来てないと思います。
と思います。
なのでKVSはRDBの代替品としてではなくより生産性の高いデータの保持方式として成長していくんじゃないかなと思ってます。
実際にOSC広島で梶山さんのお話を聞いた感想では
と感じました。
そんな感じでSQLとORMの悲劇というか宗教戦争は和解の方向に進んでると思います。
ということで無理矢理まとめますw
今の開発にRDBはとても重要な存在です。
そして現状ではRDBを使う以上、SQLは欠かせない状況です。
だからこそSQLの出来ること、苦手なことを知って欲しいですし必要です。
なぜならそれを知っていれば悲しみを生むようなDB設計も減るからです。
(私は見たことないけど1Tableにカラムが100以上あるようなDBとか)
またSQLを知ることで「未来の困りそうなことを減らせる」し「困った時に色んなアプローチを考えれる」ことでより最適解を見つけやすくなります。
(例えばPostgreSQLのウィンドウ関数)
※ウィンドウ関数についてはアドベントカレンダー初日の@choplinさんの記事がオススメ!!
私はconnect byとか是非皆さんに知ってほしいと思います。
(MySQLには無いのが非常に残念です)
なので適材適所で実際にソースコードを書いてる皆様にはSQLをもっと知ってほしいと思います。
さて明日の8日目は@fujii_masaoさんです。
PostgreSQLのアドベントカレンダーは本当に濃いので明日も楽しみですね!!
(今日も濃い話があると期待されていた方はすみませんでした)
書いたネタはせっかくなので二週目の時に公開しますね。
そしてあんまりPostgreSQLに関係ない話になりそうです、ごめんなさい。
で表題ですが元ネタがあります。
そーだいと言えばすぐORMをdisと言うイメージがあるらしいのですがまず前提として
よく考えられたDB設計で使うORMは凄く便利
ですよ。
ただ現実として後から仕様変更だったり想定外なことだったりで複雑なQueryを求められることがあると思います。
実際に開発時は大半のSQLが単純でORMで取り出すことで簡略化出来ることも多いけどそれが全てでは無いですよね。
ちょっと複雑なQueryをORMで取り出そうとすると急に難しくなり、かと言って問合せ回数を増やすようなプログラムを書くとI/Oやら負荷やらが急に上がって…(´・ω・`)
なのでORMは便利なんだから使えばいいと思いますがベストプラクティスを目指すなら発行されるSQLを理解した上で生SQLとケースバイケース使い分ける必要があります。
まさに@t_wadaさんが素晴らしいことをツイートしてて
RDBMSにはビューやストアドプロシージャがあるし、ORMにも生SQL渡し機能はある。排他的に選択するのではなく、状況(対象システム、データ量、チーム編成、良くある操作等)に応じて使い分けるのが良いのでは / “SQL上級者こそ知って…” htn.to/5wWGSL
— Takuto Wadaさん (@t_wada) 12月 7, 2012
こういうことです。
ただORMがSQLのオプティマイザーやプリコンパイラみたいに最適化されたSQLを発行するようになればSQLをあまり意識しないでもいいかもしれません。
しかしそこに現状はまだまだその領域にORMが来てないと思います。
@soudai1025 要らないことはなくても、普段php書くときに生成されるC言語までは考えなくてもいんじゃねって話しだと思うけど。だから君はORMがちゃんとしたSQLを生成するように貢献すればいいと思うんだ。
— 英吉さん (@LuckOfWise) 12月 7, 2012
これは凄く魅力的なことですが
@luckofwise ORMにDBのオプティマイザみたいなロジックがしっかりできたらそれは凄いことになると思う。けどそれってRDB使うんじゃなくてKVSみたいなモノの方が相性いいと思う。だからmongoとか流行るんだろうけど。
— そーだい@初代ALFさん (@soudai1025) 12月 7, 2012
と思います。
なのでKVSはRDBの代替品としてではなくより生産性の高いデータの保持方式として成長していくんじゃないかなと思ってます。
実際にOSC広島で梶山さんのお話を聞いた感想では
MySQLはRDBはトランザクション付きのKVSになっていくんだな #osc12hi
— そーだい@初代ALFさん (@soudai1025) 10月 20, 2012
※RDBは→RDBから と感じました。
そんな感じでSQLとORMの悲劇というか宗教戦争は和解の方向に進んでると思います。
ということで無理矢理まとめますw
今の開発にRDBはとても重要な存在です。
そして現状ではRDBを使う以上、SQLは欠かせない状況です。
だからこそSQLの出来ること、苦手なことを知って欲しいですし必要です。
なぜならそれを知っていれば悲しみを生むようなDB設計も減るからです。
(私は見たことないけど1Tableにカラムが100以上あるようなDBとか)
またSQLを知ることで「未来の困りそうなことを減らせる」し「困った時に色んなアプローチを考えれる」ことでより最適解を見つけやすくなります。
(例えばPostgreSQLのウィンドウ関数)
※ウィンドウ関数についてはアドベントカレンダー初日の@choplinさんの記事がオススメ!!
私はconnect byとか是非皆さんに知ってほしいと思います。
(MySQLには無いのが非常に残念です)
なので適材適所で実際にソースコードを書いてる皆様にはSQLをもっと知ってほしいと思います。
さて明日の8日目は@fujii_masaoさんです。
PostgreSQLのアドベントカレンダーは本当に濃いので明日も楽しみですね!!
(今日も濃い話があると期待されていた方はすみませんでした)
0 件のコメント:
コメントを投稿