Beyond Prompts: Building Intelligent Applications with Genkit and the Model Context Protocol
先日、この記事を読んで分析のハードルを下げること大事だよね、というのを思い出したのでつらつらと書いてみようと思います。 qiita.com 内容としては正直タイトル詐欺で、SlackからRDSにクエリ発行できるようにして、各種権限を持っているエンジニアでなくても分析できるようになったよ、という話です。 ここでいう「データ活用の民主化」というのはかっこ良く言ってみたかっただけで、「データ分析を生業にしている人以外もデータを活用してビジネスを進められるようになる」というくらいのニュアンスだと思って下さい。 「データ分析」というとアナリストの人がやること、みたいな職務が分かれている環境もあるとは思いますが、そうではない会社(前職)の一例です。 データ活用が広まった流れ 数秒〜数十秒で対話的にクエリが返ってくると、トライアンドエラーが100倍くらいできる 今まで実行計画を気にして避けていたことにガ
10 SQL Tricks that You Didn't Think Were PossibleAI-enhanced description The document presents a collection of SQL tricks aimed at demonstrating the capabilities and versatility of SQL as a programming language. It argues for SQL's relevance by showcasing creative uses, including recursive queries and data manipulation techniques. The author emphasizes SQL's status as a powerful, though sometimes
SQLをパースすることに迫られてPythonで自作していたが、rubyで書いたほうがより都合が良かったので書きなおしかーとなったところで見つけたいいもの。 ただし、READMEにどおりに使ってみても使えなかったのでメモ。 インストール このモジュールを使えばパースできる。 https://github.com/cryodex/sql-parser gemでのインストールは以下のようにする。 irb(main):001:0> require 'sql-parser' irb(main):002:0> parser = SQLParser::Parser.new irb(main):003:0> ast = parser.scan_str('SELECT * FROM users WHERE id = 1') irb(main):004:0> ast.select_list.to_sql No
本連載はSQLの応用力を身に付けたいエンジニア向けに、さまざまなテクニックを紹介する。SQLの基本構文は平易なものだが、実務で活用するには教科書的な記述を理解するだけでは不十分だ。本連載は、著名なメールマガジン「おら!オラ! Oracle - どっぷり検証生活」を発行するインサイトテクノロジーのコンサルタントを執筆陣に迎え、SQLのセンス向上に役立つ大技小技を紹介していく。(編集局) 今回も、前回「極めよう!分析関数によるSQL高速化計画」に引き続き、分析関数の中からウィンドウ関数とレポート関数を取り上げて説明します。 ウィンドウ関数を使った分析 それでは、ウィンドウ関数を利用して、分析してみましょう。ウィンドウ関数を使用して、累積集計、移動集計、集中集計を計算できます。今回は、ウィンドウ関数を簡単に理解してもらうために、累積集計について説明します。 ウィンドウ関数には、SUM()、AVG
github.com sqllaというSQLビルダーを書きました。特徴はある程度型安全であること、リフレクションを使用していないこと、既存のクエリビルダよりある程度高速であることです。 使い方 インストールはごく簡単で、goが入っている環境で以下のコマンドを打ちます。 $ go get github.com/mackee/go-sqlla/cmd/sqlla まず以下の様なテーブル構造を表したstructを用意します。 そして、sqllaに必要なタグを付加していきます。 また後述のgo generateで必要なコメントも足しましょう。 user.go //go:generate sqlla //+table: user type User struct { ID uint64 `db:"user"` Name string `db:"name"` } そしてこのファイルが置かれているディレ
エンジニアの南直 @south37 です。 速習会の内容 2015年12月10日に、 Wantedly のオフィスにてRailsエンジニアのためのSQLチューニング速習会を開催しました! RailsはRDBをたたく際に、Active Recordが最適化をよしなにやってくれるので複雑な処理やサービスの規模が小さい段階ではRDBに向き合う場面はすくないかと思います。しかし、サービス規模が大きくなってきたり、複雑な処理を行ったり、高速化に本気で向き合うときは、Active Recordの仮面をはぎとりSQLと向き合って細かなチューニングをおこなっていく必要があります。 今回の速習会では、SQLのチューニングの基礎として、SQLが実行されるときRDBの中ではなにがおきているか、Explainの読み方、Indexの張り方などをまとめています。 発表スライドはこちら Wantedly速習会 Want
SQLアンチパターンに登場する各アンチパターンを、出来る限り1行でまとめて俯瞰するための一覧。 記憶をたどるためのキーワードのインデックスとして使うことを目的にしている。 また、週次で別途読み合わせの勉強会を行っているため、以下の一覧は勉強会の都度更新され、併せて勉強会資料へリンクする。 Jaywalking(信号無視) 1対多または多対多の関係のテーブル間の id 管理において、Varcharなどのカラムを用意して「1,2,3,4,5」などの区切り文字で区切った値を代入すること Naive Trees(素朴な木) 親子関係を持つテーブル間の id 管理において、中間テーブルを用意せず、parent_id のような親の ID を意味するカラムを用意して代用すること ID Required(とりあえずID) どのようなテーブルにも id という名前の PRIMARY KEY を用意することだ
『RailsエンジニアのためのSQLチューニング速習会 - connpass』に参加してきました。すごく勉強になったので、 そのときのメモです。@minami7o さんありがとうございました! あとこの記事は、エムスリー Advent Calendar 2015 - Qiitaの13日目です。 🍄 スライドWantedlyの @minami7o さんの発表スライドです。 🐝 説明用のブランチ勉強会で共有されたテストデータを使えるGitHubのブランチです。 south37/sql-tuning - GitHub git clone git@github.com:south37/sql-tuning.git cd sql-tuning bin/rake db:create pg_restore -j 4 --verbose --no-acl --no-owner -d sql-tunin
みなさまごきげんよう! 嗚呼蛙でございます! 一昨日amazonアソシエイトの審査を無事通過したことを祝って、露骨なアフィ目的記事を書いてみました。 今日はデータベースの操作を行う言語『SQL』を実践的に学習できるサイトを発見したので、それについて書いていこうと思います。 SQLってなに? ブラウザ上でSQLの学習ができるサイト 日本語でのSQL学習 SQLってなに? SQLを知らない方のためにSQLについて簡単に説明しておくと、例えばネットショップで買い物をする時にこんな感じで「会員情報」「送付先」」「購入品」を登録しますよね。 【会員情報】 【送付先】 【購入品】 すると、ブラウザから入力された情報は、SQLを使ってこんな感じでデータベースに書き込まれます。 【会員テーブル】 【送付先テーブ】 【売上テーブル】 こんな風にブラウザから送られた情報をデータベースに書き込んだり、蓄積された
GitHubのエンジニアがデータベースのスローログから見つけた、LIKE句を使ったクエリーのパフォーマンス問題につながる可能性のある文字列。問題の仕組みと、それを回避するためのスニペット。 先日、例外情報のトラッカーを見回していたら、目を引くスロークエリーログを発見しました。SELECT ... WHERE ... LIKEといったクエリーのLIKE句にたくさんのパーセントが付いているのです。この部分はユーザが入力した部分なのは明らかで、最初私はSQLインジェクションを疑いました。 [3.92 sec] SELECT ... WHERE (profiles.email LIKE '%64%68%6f%6d%65%73@%67%6d%61%69%6c.%63%6f%6d%') LIMIT 10 コードを見てみると、ここで解釈されるメタ文字(%や_や\)のチェックをまったくせずにユーザが指定し
ORM使ってて、便利で余裕キメてたらn+1問題を起こしてた。 n+1問題とは 1回目 のselectで、あるテーブルのレコードの集合を取ってきて、更にまた別のテーブルから先ほど取得したレコードデータ使用して n回 selectクエリを発行してしまう現象だ。 うまく説明出来ないので下の具体例書いてみた 解決策(今回の事案の場合) JOIN使ってクエリを一回にまとめる WHERE IN使ってクエリを2回にまとめる のどちらかの対処でクエリ減らす努力をするべきだった。 具体的にどうやってしまったか friendテーブルからplayerのフレンドのレコードの集合を1回引っ張ってきて、そのレコードからまたplayerテーブルへ、フレンドのplayerデータをn回取りに行っている。 sub _get_friends_info { # 自分のフレンド関係データ(player, target)のレコードの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く