AI時代にORMなんて必要なんですかね？
新規で構築するシステムの設計を考えていて、 「今の時代にORMなんているんか？？？」 という思いに至ったので、これを書いてます。 ORMなしでAIにDBアクセスコードを生成する AIでコードを生成する前提として、 AIは生SQLを書くのが得意 オブジェクトマッピングみたいなボイラープレートをAIに生成させるコストは極小（人間が手で書くとめちゃくちゃ時間がかかる） という点が挙げられます。 そのため、AIを使う前提であれば、ORMなしで以下の作業を行っても、必要なコスト（特に時間）は極小です。 ドメイン要件を伝えてSQLを生成させる オブジェクトマッピング処理（いわゆるDAO）を生成させる 単体テストコードを生成させる というか、ドメインロジックを書いていく過程で上記のようなDBアクセスコードを、都度必要となった分だけ生成させていくのであれば、この部分の生成に時間がかかってると認識することは
人間の思考プロセスを模倣してSQLを生成する：Text2SQLエージェントの実践アプローチ｜Japan Digital Design, Inc.
本記事は、Japan Digital Design Advent Calendar 2025 の6日目の記事になります。 みなさんこんにちは！三菱UFJフィナンシャル・グループ（以下MUFG）の戦略子会社であるJapan Digital Design（以下JDD）でMUFG AI Studio（以下M-AIS）に所属し、データサイエンティストをしている小林です。 この記事は、「JDDStudy #10 MUFGのDX子会社がみた生成AIの現在地」で発表したスライドをもとに、あらためて文章として噛み砕きながら書き起こしたものです。イベントに参加できなかった方にも内容が伝わるよう、当日の流れや補足説明も交えつつ、Text2SQL に取り組んで見えてきた内容をまとめています。 ここで扱う Text2SQL とは、ユーザーが自然言語で入力した質問を、LLMが自動的にSQLクエリへと変換し、必要なデ
論理削除という技術的負債、それでも僕たちは使い続ける - じゃあ、おうちで学べる
はじめに 「論理削除？deleted_atカラム追加すればいいでしょ」この一言から始まる地獄を、何度見てきただろうか。 最初は簡単に見える。カラムを1つ追加するだけ。しかし、その「簡単さ」こそが罠だ。 論理削除は技術的負債の温床だ。WHERE句への条件追加忘れ、認知コストの増大、テストの複雑化、パフォーマンス劣化。すべては「最初にドメインを考えなかった」ツケである。 しかし現実として、サービスを運用していくと論理削除が必要になる場面は確実に訪れる。 論理削除の本質は、「このレコードは存在するが、存在しないことにしてほしい」という矛盾だ。この矛盾を解消するか、受け入れて安全に管理するか。本記事ではその両方のアプローチを解説する。 なお、私はDBのスペシャリストではないので、ここで紹介する方法が唯一の正解というわけではない。あくまで一つのアプローチとして参考にしてほしい。データベース設計は文脈
たった1行のSELECT文でシステムを停止しかけた話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「SELECT文なんて読み取りだけだし、大した影響ないでしょ」 そう思っていた時期が私にもありました。 今回は、Django Adminで作成した機能によって、本番システムを停止しかけた経験を共有します。 環境 モノリス構成（Web、DB、Appが全て1つのVM上で稼働） MariaDB 10.x系 Django + Django Admin 何が起きたのか ある日、本番環境のディスク使用率が急激に上昇していることに気づきました。みるみる増加するディスク容量に心臓が止まりだったことを今でも鮮明に覚えています。 調査してみると、
もうSQLは書かない バイブクエリが企業のデータ分析を変える
私たちがデータから答えを得る方法が、いま変わろうとしています。 何十年もの間、クエリとはSQLを書くこと、硬直したビジネスインテリジェンス（BI）ツールを操作すること、あるいはダッシュボードへのリクエストの回答を列に並んで待つことを意味していました。それは確かに機能していましたが、迅速さも柔軟性もなく、データチーム以外の大多数の人にとって決してアクセスしやすいものではありませんでした。 CDataは、この状況が変わろうとしていると確信しています。私たちはこれを「バイブクエリ（Vibe Querying）」と呼んでおり、ビジネスユーザーがデータと対話する方法を再定義しようとしています。 バイブクエリは企業がデータと対話する方法を変えるでしょう。そして、それは当たり前のものになるでしょう。 従来のクエリとは？ 従来のクエリは精度を重視して設計されています。データベースやAPIから欲しい情報（テ
タイミーのプロダクトデザイナーは全員SQLを書きます｜Yasuhiro Yokota
来月、タイミーのプロダクトデザイナー全員にSQL習得してもらうことにしたよ — Yasuhiro Yokota & STAFF / タイミー (@yktyshr) December 25, 2024 そして、タイミーのプロダクトデザイナーはSQLを書けるようになってもらいました。その取り組みについてお話しします。 私はプロダクトをデザインするときに、Figma、Notion、そしてBigQueryを常に開いています。 データをもとに仮説を立ててインタビューすることもあれば、インタビューで得られた課題のアイデアをデータで裏づけることもあります。「多くのユースケースはどうだろう？」「エッジケースは？」という疑問が湧いたら、データで知れる場合が多いです。 このように、デザイナーが大小の不確実性に向き合いながら体験を設計するのであれば、データを扱うことは基本的なリテラシーにしてよいのでは、と考えま
履歴テーブルから最新の1件を取ってくる方法 - そーだいなるらくがき帳
例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
データ分析で用いるSQLクエリの設計方法
STEP2. アウトプットを実現するために必要なデータソースを書き出す アウトプットの整理ができたら、今度はインプットとなるデータソースの整理を行いましょう。 必要なデータソースは要件から読み解くことができます。 今回は「10代のユーザーの月間視聴数（性別 / 動画カテゴリごと）の推移をグラフで見たい」という要件です。 ここから、この分析に必要なエンティティ（実体）とその属性、集計値を抽出しましょう。 エンティティと属性 ユーザー 性別 年代 動画 カテゴリ 集計値 視聴数 これらのデータを管理するテーブルを、調査やヒアリングを実施して探します。 今回は以下のテーブルを使用することとします。 user：ユーザー登録に必須な入力項目を管理するテーブル user_profile：ユーザーが登録後に設定できる任意の入力項目を管理するテーブル video：ユーザーが投稿した動画を管理するテーブル
SQL緊急救命室 | 技術評論社
概要 2011～2012年に『Web+DB Press』誌上で連載された「SQL緊急救命室」の書籍化です。病院を舞台としてダメなSQL文が毎回持ち込まれて、どこが非効率なのか、どこが間違っているのかをコミカルな対話形式で議論しながら効率的で正しいSQL文の書き方を学びます。中級者向けのSQL解説書は内容が難しく読者にとって敷居が高くなりがちですが、本書は初級者と上級者の登場人物の対話形式を採用することで物語調でスムーズに理解できるようにしています。 目次 はじめに 本書を読む際の注意事項 動作確認環境 相関名を定義するAS 本書に出てくる主要な人名 サンプルコードのダウンロード 実行計画の取得方法 本書の登場人物 初出一覧 目次 序章：本書を読むにあたってのSQLの基礎──モダンなSQLの必須技術、CASE式とウィンドウ関数 出会い CASE式──SQLが誇る強力なユーザー定義関数 CAS
SQL滅ぶべし | ドクセル
SQL • リレーショナルデータベースシステムと会話するための言語 • 1970年 Codd が RDB モデルと同時に提案 (Alpha言語) • 1974年 Chamberlin と Boyce が改良 • 元々は SEQUEL (Structured English Query Language) だったが、商標登録されていた • 読み方は エスキューエル とそのまま読む (Glliespie 2012) SQL • SQL は目的別に 4つに分けられる • DCL (データ制御言語) GRANT とか • DDL (データ定義言語) CREATE TABLE とか • TCL (トランザクション制御言語) ROLLBACK とか • DML (データ操作言語) • INSERT, UPDATE, DELETE, SELECT • データ分析者にとって重要なのは SELECT 文
もう人間がクエリを書く時代じゃない！SQLクエリの組み立てを自動化するSlack botを開発・導入しました - Pepabo Tech Portal
こんにちは。SUZURI事業部の@kromiiiと申します。 私のメインの業務はWebアプリケーションの開発ですが、大学院時代のスキルを活かして並行してデータ分析業務も行っています。 データ分析業務ではデータベースのクエリを書くことが多いのですが、私自身SUZURI事業部に配属されたばかりで、テーブルの名前やリレーションを覚えるのが大変でした。そこでクエリの設計を自動化するツールをSlackに導入しました。 その名も tbls-ask bot です。どのようなものか先に見てみましょう。 ユーザーはSlackでメンションする形で、どのようなクエリを実行したいのか自然言語で入力します。 メンションされるとSlack botが起動し、どのDBスキーマを利用するかを尋ねます。 ユーザーがDBスキーマを選択すると、自然言語からSQLクエリを生成し、Slackに返答します。 今回はパブリックに公開する
サブクエリの書き方を2万文字弱かけてすべて解説する
これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか？[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
BigQueryでクエリ一撃で29万円溶かしたけど助かった人の顔
SolanaのPublic DataをBigQueryで取得したかった# えー、お笑いを一席. ブロックチェーンSolanaのデータがGoogle Cloud BigQueryで使えるようになったというニュースをたまたまネット推薦記事でみかけた1. おや, 面白そうだ. ちょっとやってみようかな… BigQueryはさわるのが１年以上つかってないかも, どうやるんだっけ… とりあえずカラムとかサンプルでちょっとデータをみたいよな, こんな感じだっけか？ とりあえず動かしてみよう, ポチッとな. … 5秒でレスポンスが帰ってくる. おー、速い. えーっと, あれ課金データ309TB？！ いちげきひっさつ、ハサンギロチン2. BigQueryでクエリ一撃5 秒で29万円溶かした人の顔# 話題の画像生成AI, DALL･Eをつかって BigQueryでお金溶かした人の顔を表現してもらった3. あ
無料で学ぶ『達人に学ぶSQL徹底指南書 第1版』 - Qiita
はじめに 『達人に学ぶSQL徹底指南書 第1版』は、CodeZine連載とミック氏ウェブサイトの掲載記事をもとに、加筆・編集されたものです。 CodeZine連載、および、ミック氏ウェブサイトは、どちらもオンラインの無料公開コンテンツです。 今回、「書籍と元コンテンツの対応表」を作成しました。 書籍のために書き下ろされた一部コンテンツや演習問題は見れませんが、その一方、編集で割愛された内容などが含まれるので、書籍以上のことを学べる箇所もあります。 すでに新版『達人に学ぶSQL徹底指南書 第2版』が出ていますが、各テーマは第1版でも大きく変わっておらず、現在でも通用する基本的で面白い内容なので、一見の価値はあると思います。 書籍と元コンテンツの対応表 No. 目次 CodeZine連載 ミック氏ウェブサイト テーブル定義 サポートページ
競走馬の血統をSQLで再現できる! 再帰クエリ徹底活用してみた - asoview! Tech Blog
アソビュー！ Advent Calendar 2022の10日目です。 8月に入社しアソビューでバックエンドエンジニアをしている長友です。 みなさま再帰クエリ使っていらっしゃるでしょうか！ 最近アソビューではmysqlの8系へのバージョンアップを行った為、再帰クエリの利用が可能となりました。 そこで本日は、アソビュー競馬部にも所属しておりサラブレッドの血統好きな私が再帰クエリを使ってツリー構造の血統表を作成してみるというお話です。 血統表とは ~ 本稿の目的 再帰クエリについて mysqlにおける再帰クエリの構文 再帰クエリとナイーブツリー構造 血統表作成における再帰クエリ 血統表のデータ構造 血統表を作成するクエリ ポイント1. 世代を表すgenerationを0で初期化し、各再帰の中でインクリメントする ポイント2. 世代内での配置を表すpositionを初期値1で定義し、再帰で取得す
SQLを使った監視でデータ基盤の品質を向上させる - MonotaRO Tech Blog
こんにちは、データ基盤グループの吉田(id:syou6162)です。データ基盤グループでは安定してデータを利用できるように様々な取り組みを行なっています。本エントリでは、データ品質に問題がある場合にすぐに気付けるようにしたSQLによる監視の仕組みを紹介します。 背景 SQLを使った監視基盤の構築 実際の監視項目例 他チームがdailyで転送しているデータがバッチの失敗により遅れていないか BigQueryのエラーレートが急激に増加していないか 承認済みビューの設定が意図せず消えていないか 今後の展望 背景 データ基盤の運用をしていると、日々様々なトラブルと向き合う必要があります。例えば、以下のようなものがあります。 他チームがdailyで転送しているデータがバッチの失敗により遅れている TerraformなどのIaCで承認済みビューの権限管理を行なっているが、コードの設定ミスで意図せぬ状態
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLiteをRustで書き直した「Limbo」が海外で話題に — 完全な非同期I/Oのサポート、WASM対応、メモリ安全性の確保など、Rustのメリットを全面的に享受
こんなに違うよ MySQLとPostgreSQL /
SQLは滅ぶべきか｜ミック
