愛車:マツダアテンザ
Webを中心とした、ビジネス&テクノロジーに関する思いつき
by F-shin
[ このサイトについて ] [ F-shinについて ] [ トップ ]
author:えふしん
photo_20.jpg
藤川真一について


モバツイの中の人
人の良いジョンカビラと言われます。ソフト哲学者を目指します。
AMN sponsor rolls
応援します!
ツイッターやるなら
for iPhone App
Google Friend Connect
このカテゴリ[Web系]の最新30件
ワーナー作品のオンデマンド配信サービス「ワーナーオンデマンド」 動画ベーススライドプレゼンよりも、スライドベース動画プレゼンの方がWeb向き。 mixiアプリやるならAmazon EC2 モバツイが月間1億PV到達の見通し ツイッターとはなんぞや?のわかりやすい回答 ツイッターか?ブログか?思考の整理学 【Best Mobile Based Twitter App】モバツイッターがTOP5にノミネートされました。投票のご協力を!【敵はtweetie2】 【Best Mobile Based Twitter App】モバツイッターのOpen Web Awardsへの投票のご協力をお願いします! モバツイッターが日経ビジネスアソシエに掲載されました。 ネットビジネスで商標は大事です。 twitterによって世界が集約され心の戦争が起きる おまとめマンxTwitterキャンペーン セカイカメラは、21世紀のネットスケープになるか?! 「食事中なう」が無意味だと?あれ?ライフログってなんだか意味わかってる? 岡田有花さんに取材された! EC2のロードバランサーのIPアドレスが変わる罠 twitterの「つぶやき」の有効期間は2分 究極のスモールスタートの方法 自宅サーバからEC2へ 技術や用語に興味ないユーザーを「一般ユーザー」と括るのキケン アマゾンEC2 ナイトセミナ 第 2 回に出演します。 モバツイッターの政治家アカウント一時サスペンドの話 【twitter話】ネットを使う人には2種類のタイプがある ビバ☆ヒウィッヒヒーは、ネットコミュニケーションの問題をズバリ突いている うっかりしてたらモバツイの延べ登録ユーザー数が10万人を超えていました。 POPitがカラメルの商品紹介&アフィリエイトに対応! twitterは「みんなのもの」じゃない。 入力フォームの美学と現実 日本人にとって一番使われてるハッシュタグ ツイッターはステートレスなコミュニケーションでありつづけて欲しい。 夜のプロトコル「NO_04「We love twitter & tumblr.」~あの娘、ぼくがリブログ決めたらどんな顔するだろう~」に参加した。
[このカテゴリをもっと見る]
F's Garage関連
Powered by
Movable Type
■お知らせ
モバツイッターが、Open Web AwardsのBest Mobile Based Twtter Appを受賞しました!

May 04, 2008

気軽に書いてたけど、これちゃんと書いておかないとマズイか。

F's Garage:どのレベルのフレームワークが一番良いのか。
に書いた以下の部分。

確かにJavaBeansは面倒だけど、ハッシュで取り回す型のない言語は、DBのスキーマの変更は強いし。(え、select * from を使うなって?)


select * を推奨せず、カラム名を指定すべきという話についての考察がありました。

眠る開発屋blog » SELECT文でアスタリスクを使うな論、とか

列名指定のほうが必要な分だけデータを送らず転送量が減るので、または解析のパフォーマンスが上がるのでよい、みたいな話があるが、そんなに変わるの? いや、経験的にはあんまり変わらん気が。 ってか、もしMySQLであれば、クエリーキャッシュがあるので、なるべく同じ記述のSQL文を発行したほうがいい。 そもそもアプリケーションキャッシュ使えよ!とか。 となると最大公約数的な「SELECT * FROM ~」になるんじゃないのかな、という気がする。


特にrailsだなんだと言ってる文脈においては、select * fromなんてカスみたいなものかと。

そもそもWEBの場合は、眠る開発屋blog さんが引用されている先のOracleのQ&Aサイトに書いてある、「面倒でも何十個も列名を書いているのでしょうか?」などというJOINそのものがパフォーマンス上厳しいケースがある。

WEBでのDBの使われ方って、どちらかというと高速でスレッドセーフなストレージだから、そんな複雑なJOINを使うケースは部分的に限られる。

どうしても複雑になる部分は、大体キャッシュ化すべきデータであることが多いから、select * fromと書くことに多少なりともコストがかかったとしても、気にするレベルではない。

それより細かく指定して結果的にJavaと同じメンテ性になったんじゃLLを使ってる意味がないというもの。

更に、先ほどのOracleのQ&Aにおいても、そんなことよりインデックスを使わないでテーブルを見に行くようなSQLになっちゃダメよ、とか、像とアリの歩行速度の違いを語るような話になってたり。

やってはいけないのは「インデックスを使わなかったりfile sortが発生しているSQL」であって、それさえ解決されてれば、後はLLを選択する範囲での富豪的プログラムの要素に含めてしまって良いと思うので、基本的には「select * from 」を使います。

カラム名が被ってるようなテーブルの連結では指定しますけど、それはそっちの方が純粋に適切だと言うケースの場合でしょう。


## そりゃPVの桁が変われば違うんでしょうが、その場合は、重箱の隅的な最適化案のの一つとしてあげられることかもしれませんが、これを最初から予見すべしってのは反対。それでメンテナンス性を下げるならLLそのものの選択が間違いだと思うし。

■同じカテゴリ[Web系]のエントリー
<<前の記事 ネットのキラーコンテンツは旅行なのになんだそれ。
>>次の記事 テストフレームワークの話
■このblogの書き込み最新3件
グッドデザイン賞に出てたおしゃれなサイクロン掃除機がなんと半額以下。 SEOには、運用のSEOと設計のSEOの2つのフェーズがある。 ワーナー作品のオンデマンド配信サービス「ワーナーオンデマンド」
この記事への提案、提言一覧
この記事への提案、提言









あなたの情報を保存しますか?