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 文
リレーショナル・データベースの世界
序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み
毎日本番DBをダンプして、ローカルと開発環境で利用して生産性を上げてる話
シードデータで動作確認して大丈夫だったのに、本番反映してみたら想定してなかった挙動・エラーが出た😱そんな経験はありませんか。 恥ずかしながら私は今までに何回もありました。機能開発だけじゃなくバッチやマイグレーションなんかでも発生しがちなコレ。またはシードデータで動作確認できても、本番データでも通用するか検証ができないままプルリクを作る、なんていうこともあると思います。今回はこちらを無くす試みをしたお話です。 「もう本番DBで開発しちゃえばいいじゃない」の問題点 この課題を解決するには、極論すると本番DBで開発するしかないのですが、そうなると言うまでもなく以下の問題が出てきます。 レビュー通過してないコードが本番に影響を与える トライ＆エラーができない 個人情報をはじめとするセンシティブな情報が開発者の端末に漏れる データ量が多すぎてローカルに持ってこれない しかし言い換えると、これらをク
高効率なSQLクエリの書き方 - Qiita
概要 この記事では、SQLクエリをより効率的に記述するためのベストプラクティスとテクニックに焦点を当てています。データベースのクエリはシステム全体のパフォーマンスに直結するため、最適な書き方を知ることは重要です。インデックスの効果的な活用方法、適切な結合の選択、そして条件の効果的な書き方など、SQLの最適化に関する具体的な手法を解説します。各SQL文に関する実行計画の結果も掲載していますので、ぜひご確認ください。 なお、Oracle19cとOracle12cでの利用実績がありますが、他のデータベースやバージョンにおいての検証は行っておりません。 新しい情報は随時追加されますので、お楽しみにしてください。 SQLの最適化に関連する基本的なアイデア 以下の通りと考えています。 1.インデックスの利用 2.正しいJOINの選択 INNER JOIN、LEFT JOIN、RIGHT JOINなど、
【SQL】ちょっとしたパフォーマンスチューニングまとめ - Qiita
SELECT table_a.id, table_a.name FROM table_a INNER JOIN table_b ON table_a.id = table_b.id; メリットとしては、 どちらかのテーブルのid列のインデックスを使用可能 サブクエリがないことで中間テーブルが作成されない しかし、インデックスがない場合はEXISTSの方が良い場合があります ソートの回避 SQLでは暗黙的にソートが発生する演算が存在するので、 パフォーマンスにも影響するため、ソートが必要ない場合は考慮する必要があります ソートが発生する演算 GROUP BY句 ORDER BY 句 集約関数（SUM, COUNT, AVG） DISTINCT 集合演算子（UNION, INTERSECT, EXCEPT） ウィンドウ関数（RANK, ROW_NUMBER 等） メモリ上でのソートだけではなく
［速報］Google、PostgreSQLにAI対応を組み込んだ「AlloyDB AI」発表、オンプレミスでも他社クラウドでも利用可能に。Google Cloud Next '23
［速報］Google、PostgreSQLにAI対応を組み込んだ「AlloyDB AI」発表、オンプレミスでも他社クラウドでも利用可能に。Google Cloud Next '23 Googleは、8月29日（日本時間の30日未明）から米サンフランシスコで開催中のイベント「Google Cloud Next '23」で、同社が提供するPostgreSQL互換のデータベース「AlloyDB」にAI対応機能を組み込んだ「AlloyDB AI」を発表しました。 AlloyDB AIは、データベース内に保存されているデータをAIと組み合わせて利用しやすくする機能を搭載しており、企業などが持つ商品データや顧客データなどをAIで活用するアプリケーション構築を容易にします。 一般に、企業がAIや機械学習を利用したアプリケーションを開発する場合、既存の大規模言語モデルなどをそのまま利用するのではなく、自社
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発― 処理性能456万TPSと応答遅延219ナノ秒を実現 ― 日本電気（株）と（株）ノーチラス・テクノロジーズはNEDOの「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発」（以下、委託事業）において、世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」（以下、劔）を開発しました。 劔は、次世代のデータベースに用いられるハードウエア環境（メニーコア・大容量メモリーなど）に適合したシステムであり、ハードウエアの性能が向上するほどシステムの性能も高まる特性を有しています。32以上のコア数を有するハードウエアにおいては、世界最速レベルの処理性能456万TPSと219ナノ秒の応答遅延を実現しました。 劔の導入によって、複雑なバッチ処理とオンライン
SQLの実行計画の読み方 |
今回は、SQLを書く上で特にパフォーマンスに影響のあるSQLの実行計画の読み方について解説します。実行計画はデータベース製品によってさまざまに差異がありますが、ここでは比較的どのデータベース製品でも共通する内容について解説します。 実行計画とは記述したSQLが実際にデータベースの内部でどのように処理されて結果を返すか、その処理方法を記述した情報です。 A5:SQL Mk-2では、SQLエディタで実行計画を見たい SQL の上にキャレットがある状態でメニューから [SQL(S)] – [SQLの実行計画(J)] または、Ctrl+E で表示できます。 表示の仕方はデータベース製品ごとに異なりますが、多くのデータベース製品ではツリー状の情報として表現されます。（このため A5:SQL Mk-2でもツリービューで実行計画を表示します。） ツリーのリーフ（端）から処理が行われ、ルート（根）に向かっ
GWの休みに勉強しよう！！！有名IT企業の研修資料まとめ - Qiita
勉強について エンジニアの皆さん。エンジニア以外の皆さん。 ・勉強しようと思っているけど、何を勉強したらいいかわからない ・ネットを漁っても良質な教材が出てこない ・他人がどんなことをしているか気になる こんなお悩みありませんか？ 今回は、有名企業の研修資料をまとめましたので、勉強のネタにしてみてはいかがでしょうか？ 新人、ベテラン関係ありません！ GWに暇を持て余したら、こちらをご覧くださいね サイボウズ サイボウズです。 22年度の内容が公開されていました。 ■モバイルアプリ開発 ■サイボウズのアジャイル・クオリティ ■MySQL - テストデータが偏るということ ■モブに早く慣れたい人のためのガイド ■テクニカルライティングの基本 ■ソフトウェアテスト ■セキュリティ ■ソフトウェアライセンス 講義資料と講義動画まで公開されています。 資料が苦手な人でも学習が捗りますね。 ラクス こ
AWSが提唱するゼロETLとは何か？概念と登場の背景の推察 - NRIネットコムBlog
こんにちは、佐々木です。年末に書こうと思って、すっかり忘れていた宿題です。 2022年末のre:InventのキーノートでAWSのCEOであるAdam Selipskyが、『A Zero ETL future』という概念が提唱しました。言わんとすることは解るのですが、これは一体どういう文脈で、なんのためなのだろうと疑問に思う方は多いと思います。そこで、自分なりにデータ分析を取り巻く現状と課題、ゼロETLの概念が出てきた理由をまとめてみます。これは私自身の思考なので、全然違う可能性が高いですので、悪しからず。 データ分析とETLの現状と課題 ゼロETLの話をする前に、データ分析とETLの現状の話をしましょう。データ分析をする際には、必ずデータが必要です。では、そのデータはどこからやってくるのか？単一のシステム内で分析する場合もありますが、多くの場合はいろいろなシステムから必要なデータを集めて
日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud
日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud MySQL互換のオープンソースデータベース「TiDB」（タイデービー）を提供しているPingCAP社は、日本語を含む自然言語の問いをChatGPTを用いてSQL文に変換し、実行する「Chat2Query」機能を、クラウド上でTiDBのマネージドサービスを提供する「TiDB Cloud」にβ版として搭載したことを発表しました（日本語のプレスリリース） Introducing #Chat2Query, our AI-powered natural language querying tool that will release you from tedious manual SQL writing and change the way of #DataExploration
あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog
あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
MySQLからPostgreSQLに移行する際のTips - そーだいなるらくがき帳
このエントリーは Classi developers Advent Calendar 2022の18日目。 ネタはなんでもいいよ！とのことなので、Claasiに全く関係なく、MysqlからPostgreSQLに移行する際の注意点を書く。 なお、まだRDSにPostgreSQLがなかった頃のような昔の記事だがこちらに無いことを書いていく。 soudai1025.blogspot.com soudai1025.blogspot.com MySQL から PostgreSQLにデータ移行する際の注意点 MySQLとPostgreSQLは互換性がもちろんありませんので、細かいところで違いが発生します。 よく踏むデータ移行の注意点は以下の通り。 timestampやdatetimeを移行する先はtimestamp型になるが、timestamp型はタイムゾーン付きと無しがある timestamp wi
話題の AlloyDB は本当に凄いデータベースなのでプレビューを使い倒した #devio2022 | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 この度クラスメソッド株式会社で開催している技術イベント DevelopersIO 2022 のアーカイブ動画セッションに登壇しましたので、ブログで解説を行いたいと思います。なお本内容は2022年6月時点の内容となっていますので、現在の状況とは異なっている場合がございますのでご了承ください。 AlloyDB for PostgreSQL は2022年7月27日現在において、プレビューのステータスです。このプロダクトまたは機能は、Google Cloud Platform の利用規約の一般提供前のサービス規約の対象となります。一般提供前のプロダクトと機能では、サポートが制限されることがあります。また、一般提供前のプロダクトや機能に変更が加えられると、他の一般提供前バージョンと互換性がない場合があります。詳細については、リリースステージの説明
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
まだ PostgreSQL の開発で疲弊してるの？ - Qiita
{ "plpgsqlLanguageServer.database": "データベース名", "plpgsqlLanguageServer.user": "ユーザ名", "plpgsqlLanguageServer.password": "パスワード", "plpgsqlLanguageServer.definitionFiles": [ // glob をサポート。 "**/*.sql", "**/*.psql", "**/*.pgsql" ], // Language Server が対応するファイルの拡張子はデフォルトで ['*.pgsql', '*.psql'] です。 // （ SQLite など他の RDS と競合させないためです。） // '*.sql' のファイルも対応させたい場合は、下記の設定を追加してください。 "files.associations": { "*.sq
ドメインロジックとSQL - Martin Fowler's Bliki (ja)
以下の文章は、Martin Fowler による Domain Logic and SQLの日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの（rich SQL queries）を用いるので悪しからず。 エンタープライズアプリケーション（訳注：以下、EA）構築に関する本（私の近著『P of EAA』など）を読むと、ロジック
次世代SQLクライアントArctypeを触ってみる
どうも、株式会社プラハCEOの松原です 先日社内のエンジニアに「このSQLクライアントがイケてそう！」と教わったので早速Arctypeを触ってみました TL;DR クエリの補完が最高 チャートやダッシュボードを通して簡単に可視化できる 操作性に優れていて、見た目が綺麗 クエリやダッシュボードごとに権限管理できる プレースホルダーを使えば非開発者ともクエリを共有しやすい 説明しよう、Arctypeとは なんかイケてるSQLクライアントです セットアップ それぐらいしか分からないので、ひとまずDBを立ち上げて実際に使ってみようと思います。こちらのmysql-employeesを使わせていただきましょう docker run -d \ --name mysql-employees \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=college \ -v $PWD/
1文字でSQLを200倍遅くする方法
こんにちは、19のSysAd班の翠(sappi_red)です。普段はtraQのフロントエンドの保守を行ったりしています。 こんばんは、19のSysAd班のtemmaです。普段は普段どおりのことをしています。この記事の面白い部分はすべて僕が書いています。面白くないところは翠君が書いています。 この記事では、日々パフォーマンスに頭を悩ませる開発者の方のために、ワンタッチで劇遅SQLを200倍高速でキュートなSQLに劇的ビフォーアフターする方法を紹介します。 「おいおいおい、遅くしたくて記事を読み始めたのに話が違うじゃないか💢」と思ってるそこのあなた👈 早くできるということは遅くもできるんですね。 TL;DR ここにテーブルがあります。 CREATE TABLE messages ( id CHAR(36) NOT NULL PRIMARY KEY, text TEXT COLLATE ut
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
