タグ

SQLに関するaceraceaeのブックマーク (8)

  • 「雑用扱いで名前もない」 データ分析の土台を支える“SQLを叩く人”の重要性を問い直す

    「雑用扱いで名前もない」 データ分析の土台を支える“SQLを叩く人”の重要性を問い直す:これからのAIの話をしよう(データ整備人編)(1/3 ページ) データ分析をする上で欠かせない「データ整備人」とは、どんな役割を担う人なのか。ないがしろにされがちなデータ整備人の仕事について、データ分析の専門家が解説します。 多くの企業がデータの分析・活用に取り組んでいますが、その中で抜け落ちがちなのが、データ整備の視点です。データベースからデータを抽出・集計して分析者に渡す作業は地味に見えますが、データ分析の土台を支える極めて重要な仕事です。 この役割は、戦争でいうところの「兵站」(へいたん)に当たるほど重要なのではないか――データ分析に関する情報発信を続けるしんゆうさんが、自身のブログでこう問いかけた所、予想以上の反響があったといいます。 ※兵站:戦場で、前線の部隊のために軍需品や料などの供給・補

    「雑用扱いで名前もない」 データ分析の土台を支える“SQLを叩く人”の重要性を問い直す
    aceraceae
    aceraceae 2020/01/30
    というかもう仕事ではDBには触りたくないな。
  • なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!
  • 分析SQLのコーディングスタイル - クックパッド開発者ブログ

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

    分析SQLのコーディングスタイル - クックパッド開発者ブログ
    aceraceae
    aceraceae 2016/11/09
    そのシンタックスハイライトのない環境で使わなきゃならないときもあるから、紙でも目視grepしやすいようにキーワードだけ大文字派かな。あと前カンマはなんとなく気持ち悪いので使わない。
  • ちょっと変わったSQLインジェクション

    IT編集部のセミナーに出てきました 3月2日に、@IT編集部主催の「@IT セキュリティソリューション Live! in Tokyo」にて、NTTデータ先端技術の辻さんとインターネットイニシアティブの根岸さんとともに、ランチセッションに出演してきました。辻さん&根岸さんのトークに絡ませてもらい、あっという間にランチセッションは楽しく終了しました。 事前の準備中はあれだけいろいろと話そうと思っていたのに、いざ始まると時間が足りないくらい盛り上がりました。ちょっと物足りないと思うくらいがいいのかもしれませんね。その会場で使った、2002年と2012年付近の出来事を示した資料がこちらです。 私はちょうど10年前の2002年にラックに入社しました。振り返ってみればあっという間の10年の社会人生活です。こうしてみると、いろんなインシデントがリアル世界とサイバーの世界で起こっていたんだなと懐かしくな

    ちょっと変わったSQLインジェクション
  • 【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方

    SQLインジェクションを・・・駆逐してやる!! この世から・・・一匹残らず!! (PHPカンファレンス2015)

    【SQLインジェクション対策】徳丸先生に怒られない、動的SQLの安全な組み立て方
  • 新著が出ます:『SQL実践入門』 - ミックのブログ

    4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にしたで、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、当は実行計画などという手続レベルの世界をユーザが覗き見るのは、末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

    新著が出ます:『SQL実践入門』 - ミックのブログ
    aceraceae
    aceraceae 2015/03/29
    SQL 文はたまに書かなきゃなんないからなあ。最近はそんなに複雑なもの書く必要はなくなってるけど。
  • SQLデータベースに正しインデックスを作るのは 誰の役割?

    SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQL歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか? SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読

    SQLデータベースに正しインデックスを作るのは 誰の役割?
  • BigQuery と Google の Big Data Stack 2.0 - naoyaのはてなダイアリー

    先日、有志で集まって「BigQuery Analytics」という書籍の読書会をやった。その名の通り Google BigQuery について書かれた洋書。 BigQuery を最近仕事で使い始めたのだが、BigQuery が開発された背景とかアーキテクチャーとかあまり調べもせずに使い始めたので今更ながらその辺のインプットを増やして以降と思った次第。 それで、読書会の第1回目は書籍の中でも Overview に相当するところを中心に読み合わせていった。それだけでもなかなかに面白かったので少しブログにでも書いてみようかなと思う。 BigQuery の話そのものも面白いが、個人的には Google のインフラが書籍『Google を支える技術』で解説されたものが "Big Data Stack 1.0" だとして、BigQuery は Big Data Stack 2.0 の上に構築されており

    BigQuery と Google の Big Data Stack 2.0 - naoyaのはてなダイアリー
  • 1