「雑用扱いで名前もない」 データ分析の土台を支える“SQLを叩く人”の重要性を問い直す
「雑用扱いで名前もない」 データ分析の土台を支える“SQLを叩く人”の重要性を問い直す：これからのAIの話をしよう（データ整備人編）（1/3 ページ） 多くの企業がデータの分析・活用に取り組んでいますが、その中で抜け落ちがちなのが、データ整備の視点です。データベースからデータを抽出・集計して分析者に渡す作業は地味に見えますが、データ分析の土台を支える極めて重要な仕事です。 この役割は、戦争でいうところの「兵站」（へいたん）に当たるほど重要なのではないか――データ分析に関する情報発信を続けるしんゆうさんが、自身のブログでこう問いかけた所、予想以上の反響があったといいます。 ※兵站：戦場で、前線の部隊のために軍需品や食料などの供給・補充を行う機関 しんゆうさんは、データを抽出・集計して分析者に渡す人を「データ整備人」「データアーキテクト」と呼び、データ分析に関する勉強会を開催するなどの啓蒙活動
新著が出ます：『SQL実践入門』 - ミックのブログ
4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にした本で、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、本当は実行計画などという手続レベルの世界をユーザが覗き見るのは、本末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体本当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。
SQLデータベースに正しインデックスを作るのは 誰の役割？
SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
