タグ

sqlに関するlibra_666_arbilのブックマーク (26)

  • ワンランク上のSQLを書くためのポイント3つ - Qiita

    この記事はNuco Advent Calendar 2022の17日目の記事です。 ワンランク上のSQLとは? 1年近く、データ分析に関わる業務に携わっってきた中で、良いSQL、いまいちなSQLをいろいろ見てきました。 自分が書くSQLも、最初の頃は目も当てられないSQLも書いてきました。そんな中で、こんなことを意識していくと、より良いSQLになるのでは?というポイントをまとめていきます。 とりあえずSQLの文法は一通り勉強して、取得したいデータをとってくるSQLをかけるようになったぞ。という人に向けたものなので、当に基礎的な文法は解説していません。 ワンランク上のSQLを書くためのポイントは、 ・読みやすい ・再利用しやすい ・処理が早い の3つを押さえられているかどうかだと感じています。 可読性が高いメリット 間違いにくくなる/デバックが容易になる エラーが出てくれれば間違っているこ

    ワンランク上のSQLを書くためのポイント3つ - Qiita
  • マーケティング担当者にSQLを完全マスターさせた話 - Qiita

    普段開発とかしない人達にもデータベースに簡単に触れられるようにしたお話です. 安全なデータベースを作る 番サービスのデータベースと同等,だけど個人情報的なものは隠しておきたい,よく聞く話ですね. これについては様々なアプローチがあるようですが,できる限り安定させたい&バッチでやるにしてもサーバの面倒を見たくない,とう方針のもと,RDSのスナップショットを利用して作成することにしました. 処理の流れ RDSが1日1回スナップショットを取っている(これはRDSの機能) RDSのスナップショットが取られると,RDSからイベント通知が投げられるので,SNS→SQSへ届くようにしておく(これもRDSの機能) CloudWatchでSQSのキュー数を監視するようにしておき,キューが1つ以上になると処理用のインスタンスを立ちあげる設定にしておく(CloudWatch,AutoScalingの機能) イ

    マーケティング担当者にSQLを完全マスターさせた話 - Qiita
  • 実行計画が解れば怖くない。SQL実践入門 - プログラマでありたい

    技術評論社さんから、SQL実践入門を献いただきました。ありがとうございます。 SQL実践入門の主題 このの目的は、「パフォーマンスの良いSQLの書き方、特に大量データを処理するSQLの性能向上の方法を理解すること」とあります。そのパフォーマンス向上の為の解として、SQLが内部的にどう処理されているかを表す実行計画の読み解き方を、いろいろなケースを上げながらひたすら解説しています。そして、何故その実行計画になるのか、データ構造やDBの動きとともに説明しています。ということで、実行計画大事という基かつ当たり前のことを、正面から取り扱っている良質のSQLです。 SQL実践入門の構成 SQL実践入門の章立ては、下記の通りです。 第1章:DBMSのアーキテクチャ──この世にただ飯はあるか 第2章:SQLの基礎──母国語を話すがごとく 第3章:SQLにおける条件分岐──文から式へ 第4章:集約

    実行計画が解れば怖くない。SQL実践入門 - プログラマでありたい
  • SQLスタイルガイド - Qiita

    はじめに 文書はSQLのスタイルガイドです。 PythonRubyのようなプログラミング言語には有名なスタイルガイドがあり、共通のレイアウトルールに沿ったインデントや命名規則に則ったコードが生み出されています。 一方、SQLには知名度のある統一されたスタイルガイドがありません。 そのため、思いのままに書かれたSQLが散見されます。 もちろん、SQLを使ってアドホックな分析を行う場合は、必ずしもルールに沿う必要はなく、効率よく書いても良いと思います。 しかし、Webサービスやバッチの中に組み込むようなもの、つまり自分以外の誰かに読まれるSQLは、多くのプログラミング言語同様に何らかのスタイルガイドに沿うことで多くのメリットを享受できると思います。 クエリが構造化され、可読性が高まる バグの発見や修正が容易になる 改行位置やインデントなどのフォーマットの悩みが解消される スタイルガイドを共

    SQLスタイルガイド - Qiita
  • 30 SQL Developer Tips in 30 Daysをテキトーに訳した(1~15) - kagamihogeの日記

    http://www.thatjeffsmith.com/のaboutによるとProduct Manager for Oracle, working on the SQL Developer teamという方が主にSQL Developerについて書かれているブログがあります。詳しい経緯は不明ですがSQL DeveloerのTipsについて30日間連続で書き続けるという、ひとりAdvent Calendarのようなチャレンジをしておられます。このエントリではそのチャレンジに敬意を表すると同時に、テキトー翻訳をしていきます。 このエントリではTipsの1から15まで訳しています。 なお、下記翻訳文中の「私」は特に断りが無い限り引用元のJeff Smith氏のことを指します。また、画像はすべて同氏のブログに張られているものを参照しています。 30 SQL Developer Tips in 3

    30 SQL Developer Tips in 30 Daysをテキトーに訳した(1~15) - kagamihogeの日記
  • エロゲーマーのためのSQL -エロゲーマーのためのSQL-

    SQLはデータベースからデータを抽出したりするための言語です。 この文書は、ErogameScapeのデータベースからSELECTを使って自由自在にデータを取得できるようになることを目標にします。 エロゲーをやりはじめる大学生くらいのときに、大学の講義でデータベースを学んで、退屈だなーと思った時に、ErogameScapeでSQLを学ぶことで、少しでもSQLに興味を持って、自身でデータを加工することを学習して頂けると幸いです。 ※私の大学のリレーショナルデータベースの授業では、自分の身の回りの何かをER図に落とし込んで、DBを設計し、PostgreSQLに実装し、実際にデータを入力してSELECTしてみるところまでをやりました。 ER図という概念を学んだとき「ああ、これは面白い」と思いました。 先生はこう言ったのです。 「ER図に落とし込むと、思いもよらなかったことが分かる。」と。 当時、

  • もうちょっと「艦これ」からSQLを考えてみる3 - SQLer 生島勘富 のブログ

    前回の続き。 前回のパターンであれば、全体を(パフォーマンス・サーバの負荷・開発工数・メンテナンス性)を鑑みて、IF文と四則演算は、DBサーバより、APサーバ。APサーバより、クライアントにある程度キャッシュさせて、処理もクライアントで行った方が良いです。 そう判断するには、設計段階でSQLで処理したときどうなるか、SQLで処理しなかったときどうなるか。が正確に分かってないと判断できません。 例えば、「艦これ」からは随分と離れますが、あるテストの男子と女子、全体の平均と最高点・最低点を求めたいとする。(面倒なので性別は非正規化されているとする) テーブルは以下の通り 成績テーブル テストID 生徒番号 性別(1:男子、2:女子) 得点 1.SQLで処理する SELECT テストID , AVG(CASE WHEN 性別 = 1 THEN 得点 ELSE NULL END) AS 男子平均

    もうちょっと「艦これ」からSQLを考えてみる3 - SQLer 生島勘富 のブログ
  • SQLServer用のSQLメモ - 馬車馬のクリップボード

  • SQLアンチパターン - ナイーブツリー

    より詳細なCQRSに関する資料はこちら https://little-hands.hatenablog.com/entry/2019/12/02/cqrs 参考資料:http://little-hands.hatenablog.com/entry/jjug2017fall 社内新規プロダクトでDDD, CQRSの思想をベースとしたアーキテクチャを構築し、コマンド(更新系処理)ではSpring Data JPA(Hibernate)を、クエリ(参照系処理)ではjOOQを採用しました。 結果としてそれぞれのORMの良いところを生かした組み合わせのアーキテクチャが構築できたので、その経緯と得られた知見についてお話ししたいと思います。 以下のようなトピックを考えています。 ・CQRSの定義とメリットデメリット ・DDD,CQRSを検討するにあたってのORMの選定ポイント ・構築したアーキテクチャ

    SQLアンチパターン - ナイーブツリー
  • 遅いSQLって » DAのコラム

    HOME   >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>     株式会社 MRT 遅いSQLって 品質の問題? 開発者は、SQLをつくって正常な結果が取得できればテストOKとなる事がおおいのですが、明らかにSQLの問題のプログラムのレスポンスが悪い場合、開発者に責任はないのでしょうか? ・テストケースでは、データ量が少量でのテストだけで実運用でデータが増えた場合のテストを行っていない ・データ件数のMAX値でのテストを行っていない。 こんなSQLで納品されて、運用を開始後数カ月たって問題が持ち上がるケースがよくあります。 SQLのレスポンスを改善した時の、問題となったSQLを見たいとあげてみたいと思います。 ■静的なSQLで、全ての条件の項目が「LIKE」になっている。 画面からの入力項目が条件になっているのですが、静的なSQLなので、全ての項目をLI

  • 出張デコパパ日記: Oracleチューニングが楽しい

    NAS、サーバ W-ZERO3 システムエンジニアリング パソコン・インターネット プログラミング 日記・コラム・つぶやき 書籍・雑誌 育児 年明けから、別プロジェクトのヘルプをしている。Javaのコードを改修したり、パフォーマンスに問題のある処理を改良したり、業務に深く踏み込まない程度のレベルで色々と手伝いをしている。最近まで、SQLのチューニングについては大して知識を持っていなかったが、今回のようなヘルパー業務ではその辺が必須になってきたので、勉強しながらやっている。最適なチューニングによって劇的に性能が改善すると、ゾクゾクとクるものがある。性能が出ないで苦労している現場には悪いが、正直楽しい。 Oracle上で動作するSQLをチューニングする場合、まず実行計画を見るところから始まる。 修正を頼まれるのは何十万行というデータをJOINしまくり、応答があるまで数十秒、下手をすると数分また

  • PL/SQL等のバッチ処理でたまに見かける最悪なプログラム - suVeneのアレ

    今日はプログラムの話 & 愚痴。 プログラムしてる時は、わりと静かに黙々と作業している(と思う)。 ただ突然「あほかっ!」と叫んでしまいたくなることがある。いや、さすがに叫びはしないが、小さく呟くくらいはしているかもしれない。 (よくゴニョゴニョいいながらカチャカチャやってるプログラマーみたいな) 叫びたくなるプログラムとは?DB更新を含むバッチ処理などで Pro*C 使ってたり PL/SQL 使ってたりするプロジェクトはよくあると思う。叫びたくなるのは、そういうプロジェクトの中で他人のプログラムを修正している時だ。 とは言っても、ソースが汚いとか main() や BEGIN END の間に全部の処理書いてるとか、それくらいでは叫びはしない(ていうか、全部直してる訳にはいかないので)。 ではどういう時かというと、「パフォーマンスが出ない」「バッチが朝までに終わらない」などと、オロオロして

    PL/SQL等のバッチ処理でたまに見かける最悪なプログラム - suVeneのアレ
  • DB エンジニアのための勉強会に参加して SQL アンチパターンは必読だと確信したので読むことに決めた! #dcampjp #sqlap - #garagekidztweetz

    ツイート@nippondanji な師匠が特別寄稿したという記事を読んでいての存在は知りつつ、先日の devsumi では満席のため聴講できなかった SQL アンチパターンの話を直接聞ける機会をもらえるということで、喜び勇んで参加してきました。 裏でやっていた #awssummit Day2 とギリギリまで天秤にかけていたのですが、あまりにも#awssummit の Day1 の印象が悪かったので、こちらに参加することにしました。 どうでもいいことですが 富士ソフトアキバビル 1F の案内が 「PB エンジニアのための勉強会」になっていたwさて、勉強会の概要は以下のとおりで、 開催概要: DBエンジニアのための技術勉強会 主催: エンバカデロ・テクノロジーズ 日程: 2013年6月6日(木) 13:30〜16:15 (13:15 受付開始) 会場: 富士ソフト アキバプラザ 6階 セ

    DB エンジニアのための勉強会に参加して SQL アンチパターンは必読だと確信したので読むことに決めた! #dcampjp #sqlap - #garagekidztweetz
  • SQL的(集合的)考え方と、ループ(手続き型)の考え方3 - SQLer 生島勘富 のブログ

    問題を少し変更 問題)部品在庫から、作成可能な製品の情報をとる。 ※来はマスタテーブルと組み合わすべきですが、ツールの関係上2テーブルしか同時に表示出来ないので名称で結合する形になります。 SQLで考えるなら という風に考えます。 言い換える 『在庫数が必要量を満みたす製品のみ』 → 『在庫数が必要量を満たさないレコードがある製品を削る』 『満たさない』= NOT EXISTS(あるいは、NOT IN) 答えは SELECT * -- 当は必要なもののみ FROM 部品表 AS bh INNER JOIN 在庫 AS zk ON bh.材料名 = zk.材料名 WHERE NOT EXISTS (SELECT * FROM 部品表 AS bh_s INNER JOIN 在庫 AS zk_s ON bh_s.材料名 = zk_s.材料名 WHERE bh_s.製品名 = bh.製品名 -

    SQL的(集合的)考え方と、ループ(手続き型)の考え方3 - SQLer 生島勘富 のブログ
  • 新著が出ます:ジョー・セルコ『プログラマのためのSQL 第4版』 - ミックのブログ

    皆さん、お久しぶりです。長らくブログの更新が止まっていたのは、少し大きな仕事をしていたためです。ジョー・セルコ『プログラマのためのSQL 第4版』の翻訳。これに集中するため、ブログもやらずTwitterもやらず(こっちはちょっとやってしまった)頑張っておりました。 長かった。 当に長かった。 原著が800ページ以上あるうえ内容も簡単ではないので、もともと楽な仕事とは思っていませんでしたが、いや大変でした。ですが無事今月刊行とあいなりました。すでにAmazonはじめオンラインショップでも予約受付を開始しています。あらかじめ言っておきますが「表紙のおっさん誰?」という質問は私にはしないように。私も答えられないので(笑)。 さて、書の内容を紹介する代わりに、少し長くなりますが訳者前書きを引用します。購入するか判断の参考にしていただければと思います。なお、実行環境としては前書きでも書いています

  • Oracleのロックの調査と解消(V$LOCK、V$SESSION、V$LOCKED_OBJECT):老プログラマーの備忘録:So-netブログ

    ロックの調査 ロック競合が発生している可能性がある場合は、V$LOCK、V$SESSION、V$LOCKED_OBJECT(V$LOCKのビュー)でロックの情報を取得しALTER SYSTEM KILL SESSIONでセッションを開放しロックを開放します。 セッション(SID)、ユーザー、オブジェクト及びプログラム等の項目を調査しロックの解消と原因を調べます。 ロックのセッション、ユーザ、オブジェクト及びプログラム名を表示 Select V$SESSION.SID, DBA_OBJECTS.OBJECT_NAME, V$SESSION.OSUSER, V$SESSION.PROGRAM From V$LOCKED_OBJECT Left Join DBA_OBJECTS on V$LOCKED_OBJECT.OBJECT_ID = DBA_OBJECTS.OBJECT_ID Left J

    Oracleのロックの調査と解消(V$LOCK、V$SESSION、V$LOCKED_OBJECT):老プログラマーの備忘録:So-netブログ
  • サービス終了のお知らせ

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

  • Google Sites: Sign-in

    Not your computer? Use a private browsing window to sign in. Learn more about using Guest mode

  • SQLチューニング

    SQLのチューニングをする際に、チェックする観点を掲載します。 最低限、これだけはチェックして欲しい内容です。 これらをチェックするには、人・工数・決断を必要とします。 開発メンバーの士気は下がり、場合によってはプライドすらも 傷つけます。 時間が無いのに、新たな作業を言い渡される訳ですから・・・ だ・か・ら、納期ギリギリでは「つらい」のです。 ※しかし、港は無表情で作業の依頼を指示します。 (まぁ、殴られたり、刺されたりした事は無いので・・・) どうぞ参考にして下さい。 【チェック内容】 01.サブクエリを引数に取る場合、IN述語よりもEXISTS述語を 使っているか SELECT name FROM Personnel WHERE birthday IN (SELECT birthday FROM Celebrities); ▼ SELECT P.name FROM Personnel

  • SQLを早くする - ゾイの備忘録Wiki