タグ

SQLに関するbfojのブックマーク (11)

  • Text-to-SQLについて考えていることをだらだらと書く - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、Text-to-SQL という技術が注目されています。複数のテーブルデータに対して自然言語で質問すると、その質問の回答に必要なデータの取得・集計などをしてくれる技術です。BI ツールの使い方や SQL の書き方に詳しくない人でもデータ分析できるという点で重要な技術です。 ただ、Text-to-SQL 自体やその周辺技術に関していろいろ思うところもあるので、つらつらと書いていきたいと思います。特に技術検証記事ではないポエムに近い内容ですが、ご容赦ください。 0. サマリー? Text-to-SQL がサポートしないデータ分析のプロセ

    Text-to-SQLについて考えていることをだらだらと書く - Qiita
  • PGlite + pgvector で100行で実装するベクトル検索 (node/deno/drizzle)

    pglite + pgvector で文章の類似度検索を実装します。 動機 とにかく手っ取り早くローカルにデータを突っ込んでおいて検索する RAG の雛形がほしかったんですが、調べても大規模ストレージを前提とした大掛かりな実装が多いです。 スクリプトを書いたらポンと実行できるセットアップ不要なものがあると、色々と実験ができます。 mastra/rag を読んでたら、簡単にできる気がしたのでやりました。ただ、chunk のドキュメント分割相当のものはまだ作ってません。そこまで難しい概念でもないので、雑に作れそうではあります。 qrdrant も検討しましたが、サーバーを建てるのが面倒でした 準備: ベクトル化用の関数 今回は @ai-sdk/openai を使ってベクトル化をします // OPENAI_API_KEY= import { openai } from "@ai-sdk/open

    PGlite + pgvector で100行で実装するベクトル検索 (node/deno/drizzle)
  • なぜ DuckDB を採用したのか

    概要 なぜ 自社 で DuckDB を採用したのかを、雑に書いていきます。 変更履歴 2025-03-12: DuckDB の開発体制と Zstandard で圧縮されたファイルの読み込みについて追記 2025-02-13: 今後やりたい事 v2 を追記 まとめ DuckDB / DuckDB-Wasm を利用する事で中小規模のサービスであれば、ログ解析や統計情報の可視化を低コストで提供することができる DuckDBgo-duckdb 経由で利用する事で、HTTP リクエスト単位での DuckDB を利用できる DuckDB-Wasm と OPFS を利用する事で、クライアント側での統計情報のため込みができるようになる 解決したい課題 解決したい課題は基的にサービスの運用費を抑えるということです。中小規模のサービスでは運用費が大きな課題になります。 自社パッケージ向けのログ解析ツー

    なぜ DuckDB を採用したのか
  • Announcing TypedSQL: Make your raw SQL queries type-safe with Prisma ORM

    Generate query functions by using the --sql flag on prisma generate: Import the query function from @prisma/client/sql … … and call it inside the new $queryRawTyped function to get fully typed results 😎 If your SQL query has arguments, they are provided to the query function passed to $queryRawTyped The Prisma Client API together with TypedSQL provides the best experience for both CRUD operations

    Announcing TypedSQL: Make your raw SQL queries type-safe with Prisma ORM
  • WebAssemblyとしてPostgreSQLをビルドした「PGlite」公開。Node.jsやブラウザ上でPostgreSQLを実行、DBの永続化も可能

    PostgreSQLのソースコードをWebAssemblyバイナリとしてビルドしたことで、Node.jsなどのJavaScriptランタイムやWebブラウザ上で(ほぼ)フル機能のPostgreSQLを実行可能にした「PGlite」が公開されました。 PGliteはPostgreSQLのCのソースをEmscriptenでコンパイル PostgreSQLはオープンソースの代表的なリレーショナルデータベースであり、C言語で開発されています。 PGliteはこのPostgreSQLのCのソースコードのビルドにEmscriptenコンパイラを使用してWebAssemblyバイナリとして出力、JavaScript/TypeScriptからライブラリとして呼び出せるようにしたものです。 ただしEmscriptenでコンパイルされたプログラムは新しいプロセスをフォークできないため、PGliteはPostg

    WebAssemblyとしてPostgreSQLをビルドした「PGlite」公開。Node.jsやブラウザ上でPostgreSQLを実行、DBの永続化も可能
    bfoj
    bfoj 2024/08/19
    ネイティブアプリ、専用クライアント、リッチクライアント時代のローカルDBを活用したアーキテクチャ/パターンを現代に復活させねば。あまりファットクライアントにしたくはない。
  • マルチエージェントで性能が上がったText-to-SQLのいま/Text-to-SQL

    AIエージェント時代のエンジニアになろう #jawsug #jawsdays2025 / 20250301 Agentic AI Engineering

    マルチエージェントで性能が上がったText-to-SQLのいま/Text-to-SQL
  • データ基盤のためのリーダブルSQL

    これは何? 私tenajimaがデータ基盤のパイプラインを作るとき、レビューするときに意識している点を言語化したものです データ基盤を作る上での考え方の一つに役立てていただければ幸いです この記事の前提 dbtを使ったデータ基盤構築を念頭に置いて書いています、dbtの記法が出てきます CTEsが使える環境を想定しています 記事内でデータエンジニアもアナリティクスエンジニアも総称してデータエンジニアと呼んでいます データ基盤を「使う側」のクエリと「作る側」のクエリの違い 最近ではファーストキャリアからデータエンジニアの方も出てきているかもしれませんが、データサイエンティスト、アナリスト、ソフトウェアエンジニアを経験してデータエンジニアを行っている人が一般的と考えています。 特にデータサイエンティスト、アナリストからデータエンジニアへの転向は私の周りでは多いように感じており、その方達は(過去の

    データ基盤のためのリーダブルSQL
    bfoj
    bfoj 2024/05/21
  • WITH句かサブクエリか - まずは蝋の翼から。

    SQLにおいて、サブクエリは可読性下がるからWITH句を使えという話をしばしば聞く。 ただ、最近あえてサブクエリで記述している人がいたので WITH句とサブクエリで何が違うか について考えてみた。 同じ抽出内容だが片方はWITH句、片方はサブクエリで書いた以下のSQLをベースに話す。 WITH句 WITH sub1 AS ( SELECT aaa ,bbb FROM tbl1 ) ,sub2 AS ( SELECT xxx ,yyy FROM tbl2 ) SELECT sub1.aaa ,sub1.bbb ,sub2.xxx ,sub2.yyy FROM sub1 INNER JOIN sub2 ON sub1.aaa = sub2.xxx ; サブクエリ SELECT sub1.aaa ,sub1.bbb ,sub2.xxx ,sub2.yyy FROM (SELECT aaa ,bb

    WITH句かサブクエリか - まずは蝋の翼から。
    bfoj
    bfoj 2024/05/19
  • サブクエリの書き方を2万文字弱かけてすべて解説する

    これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか?[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

    サブクエリの書き方を2万文字弱かけてすべて解説する
  • リレーショナル・データベースの世界

    序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記:その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み

    bfoj
    bfoj 2024/04/14
  • データ分析のためのSQLを書けるようになるために

    はじめに 稿では分析用クエリをスラスラ書けるようになるまでの勉強方法や書き方のコツをまとめてみました。具体的には、自分がクエリを書けるようになるまでに利用した教材と、普段クエリを書く際に意識していることを言語化しています。 想定読者として、SQLをガンガン書く予定の新卒のデータアナリスト/データサイエンティストを想定しています。 勉強方法 基礎の基礎をサッと座学で勉強してから、実践教材で実際にクエリを書くのが望ましいです。 実務で使える分析クエリを書けるようになるためには、実務経験を積むのが一番良いですが、だからといって座学を御座なりにして良いというわけではありません。SQLに自信がない人は、一度基礎に立ち返って文法の理解度を確認した方が良いと思います。 書籍 SQL 第2版: ゼロからはじめるデータベース操作 前提として、SQLに関する書籍の多くがデータベース運用/構築に関する書籍がほ

    データ分析のためのSQLを書けるようになるために
  • 1