SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
2020/9/30追記 本記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、本記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか？ 今回は、そんな方々にこそ
Apache Sparkコミッターが教える、Spark SQLの詳しい仕組みとパフォーマンスチューニング Part1
2019年3月19日、Data Engineering Meetupが主催するイベント「Data Engineering Meetup #1」が開催されました。データの収集や管理、処理、可視化など、データエンジニアリングに関する技術の情報を共有する本イベント。データエンジニアリングの最前線で活躍するエンジニアたちが集い、自身の知見を共有します。プレゼンテーション「Deep Dive into Spark SQL with Advanced Performance Tuning」に登壇したのは、Databricks Inc.の上新卓也氏。講演資料はこちら Spark SQLの仕組みとパフォーマンスチューニング 上新卓也氏：それでは発表を始めます。『Deep Dive into Spark SQL with Advanced Performance Tuning』ということで、Spark SQ
初心者のためのSQLガイド???? : SQLを直感的に理解しよう | POSTD
SELECT * WHERE a=b FROM c ？ それとも SELECT WHERE a=b FROM c ON * ？ もしあなたが私のようなプログラマだったら、SQLは、初めは優しく見える言語の1 つかもしれません（ただ単に普通の英語通り読めばいいですから）。ですが、何かしらの理由で、なんてことのないクエリにもいちいち正しいシンタックスをググらなければいけないでしょう。 いずれJOINにAGGREGTATION、サブクエリにたどり着くでしょうが、読んだとしてもさっぱりでしょう。例えば次のような感じです。 SELECT members.firstname || ' ' || members.lastname AS "Full Name" FROM borrowings JOIN members ON members.memberid=borrowings.memberid JOIN
DBI-DBDについて
DBI/DBDの使い方 この文章は、perlでcgi等のプログラムができ、SQLの基本的な使い方を知っているひとを対象に書かれています。 また、DBI/DBDモジュールを利用するには、perl5のオブジェクト指向（風）プログラミングの知識もある程度以上は必要です。 DBI/DBDとは、perlとデータベースの間をとりもってくれる汎用インターフェイスです。 DBIモジュールとDBDモジュールからできており、DBDモジュールは、各データベースごとに存在します。 プログラマは、DBIモジュールのルールにしたがってプログラミングすることで、どのようなデータベースにも、同じようにアクセスするプログラムを書くことができます。 ここでは、DBD/pg（PostgreSQL用DBDモジュール）を使った例を提示しますが、基本的には、どのようなDB相手でも同様のことができます。
第10回 結合大全 （5）非等値結合 | gihyo.jp
非等値結合 自己結合の用途 ところで、この自己結合というのは、いったいどういう局面で使う結合なのでしょう。これも業務によってはあまり利用しない人も多いかもしれません。 実は、自己結合というのは、SQLにおいてはほぼ用途が決まっています。それは、「行間比較」をしたい場合です。行間比較とは、たとえばランキング（順位）算出のように行をまたいで条件を比較するような演算のことです。 自己結合＋非等値結合 そして、そうした行間比較を行う場合、自己結合とほとんど常にセットで使われる演算が、非等値結合です。これは文字通り、結合条件に等号以外の<>や<=を使う結合方法で、多くの場合は不等号を使います。 たとえば、図1の部署テーブルに対して「自己結合＋非等値結合」を使う例としてリスト6のようなコードが挙げられます。実行結果は図10のようになります。 リスト6 図1の部署テーブルに対して「自己結合＋非等値結合
自己結合の使い方
はじめに SQLが提供する結合演算には、その特徴に応じて内部結合、外部結合、クロス結合などさまざまな名前が与えられています。普通、これらの結合の多くは、異なるテーブルまたはビューを対象として行われます。しかし、SQLは結合が同一のテーブルまたはビューに適用されることを禁止していません。同一のテーブルを対象に行う結合を「自己結合（self join）」と呼びます。自己結合は、使いこなせば非常に便利な技術ですが、動作がイメージしにくいため敬遠されがちです。そこで本稿では、この自己結合の便利さを例題を通して学び、その動作を分かりやすく解説します。 自己結合を理解することは、実務上のテクニックを身につける以外に、もう一つ利点があります。それは、集合指向（set-oriented）というSQLの重要な特徴を理解できることです。オブジェクト指向言語が世界をオブジェクトとして表現するように、SQLは世界
いまどきのカジュアルなデータベース関連開発
profile id: Songmu (ソンムー) Masayuki Matsuki http://www.songmu.jp/riji/ https://metacpan.org/author/SONGMU カヤック技術部ソーシャルゲーム事業部 二年半ソーシャルゲーム漬け 今年新たに上げたCPANモジュール Riji Puncheur DBIx::Schema::DSL Cache::Redis Config::PL Redis::LeaderBoard DBIx::FixtureLoader SQL::Maker::Plugin::JoinSelect Teng::Plugin::SearchJoined Git::Repository::FileHistory GitDDL::Migrator UnazuSan Plack::Middleware::Woothee Plack::Mi
3値論理とNULL
要するに、データベースにnullが1つでも含まれていれば、クエリから正しくない結果が返される可能性がある。しかも、一般的には、どのクエリから正しくない結果が返されるのかを知る方法はないので、すべての結果があやしく見えてくる。nullが含まれたデータベースから正しい結果が得られることは確信できない。筆者に言わせれば、この状況はまさにお手上げである。 ――――C.J.デイト はじめに 多くのプログラミング言語が、真理値型（BOOL型、BOOLEAN型）というデータ型を持っています。もちろん、SQLにも真理値型が存在します。ユーザーが直接扱えるデータ型として定義されたのはSQL-99ですが、WHERE句などの条件の評価時にも真理値の演算が行なわれています。 ところで、普通のプログラミング言語の真理値型とSQLの真理値型の違いをご存知でしょうか？ それは、普通の言語の真理値型が、true、fals
REPLACE INTOが実はINSERT + DELETEだった（INSERTが先で後から消す） 間違ってました。。
REPLACE INTOが実はINSERT + DELETEだった（INSERTが先で後から消す） 間違ってました。。 「INSERT .. ON DUPLICATE KEY UPDATE ..でクエリを投げているけど、99%くらいはUPDATEになっている」 「UPDATEを直接投げた方が速かったりする？」 「極端にパフォーマンス違うんだったら、UPDATEが転けてからINSERTする方式も考える」 とか聞かれたのでINSERT .. ON DUPLICATE KEY UPDATEについて調べてたんですが、 ソース読んでたら豆知識に出会ったのでメモ。 5.6.10のsql/sql_insert.ccの中でゴニョゴニョしている気配があるけど、write_record関数の中で table->file->ha_write_row(table->record[0]してみる。 ⇒何もないINSE
ロック待ちでハマる前に知りたかったMySQL InnoDBの行ロックとテーブルロックの挙動
整合性をしっかりとらないといけない処理ではトランザクションをかけるのですが、どうもトランザクションのロック待ちでタイムアウトしてしまうことがあるようです。 java.sql.SQLException: Lock wait timeout exceeded; try restarting transaction トランザクションでテーブル全体にロックがかかってしまう 要するに、「トランザクションを実行するためにロックを獲得しなければいけないが、他のコネクションがロックを握っていて、ロックが獲得できない」ということです。 これの根本的な原因は何かと調べますと、InnoDBでトランザクションを使用するときに、行ロックではなく、テーブル全体にロックがかかってしまう場合がある、というところにたどり着きました。 「InnoDBで行ロック/テーブルロックになる条件」を見ながら、少し試してみます。 テーブ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
相関サブクエリで行と行を比較する
Loading...
SQLのUpdate文に関する質問です。 複数のテーブルの値を加減算して、特定テーブルの値を更新するSQLは、以下のテーブル例ではどのように記述すれば良いでしょう…