[B! SQL] yukisaltoのブックマーク

yukisalto id:yukisalto

SQLに関するyukisaltoのブックマーク (5)

SQLチューニング～お手軽に使えるヒント句まで - Qiita
ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら全般的に共通の考え方で対応できると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく、またインデックスを乱立すると複数の条件がある時などにオプティマイザが誤作動を起こす要因ともなります。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。基本的にルールベースと違いコストベースになるのでオプティマイザによって作成される実行計画が望み通りの計画になっているのかを見ながらチューニングしていく必要があります。今まで見てきた遅いSQLはとんでもない結合順や使用されるインデックスがなんでここから？といった実行計画になっていた事が大半でした。そういう時に正しい実行計画をオプ
yukisalto 2017/02/14
チューニング

SQL
リンク
分析SQLのコーディングスタイル - クックパッド開発者ブログ
SQL、書いてますか？こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？という点です。イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、いまいち決定版と言えるスタイルがないなと感じています。そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。特に、分析
yukisalto 2016/11/09
きれい

SQL
リンク
サービス終了のお知らせ
サービス終了のお知らせいつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。お客様がアクセスされたサービスは本日までにサービスを終了いたしました。今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。
yukisalto 2016/02/12
SQL

チューニング
リンク
30分でわかるER図の書き方 (10) - とあるソフトウェア開発者のブログ
前々回、前回に引き続き、ER図に関する補足的なトピックを扱います。今回は、交差エンティティについて説明します。前回: id:simply-k:20100714:1279071645 次回: - 目次: id:simply-k:20100716:1279237959 多対多のリレーションシップ次の図を見てください。この図を見ると、「商品」と「仕入先」の間に、多対多の関連がある事をがわかります。ER図としては、特に問題はありません。しかし、このER図を元にしてリレーショナル・データベースのテーブル設計をする場合、次のような問題が発生します。ある商品が、どの仕入先(複数)と対応するのかを、データとして保持できない。ある仕入先が、どの商品(複数)と対応するのかを、データとして保持できない。このような場合、交差エンティティ(intersection entity)と呼ばれるエンティティを
yukisalto 2016/01/20
SQL
リンク
SQLアンチパターン幻の第26章「とりあえず削除フラグ」
SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less
yukisalto 2016/01/05
SQL
リンク
1