【MySQL5.6】完全外部結合(FULL OUTER JOIN)のやりかた - Qiita※例となるようなSQLは一番下にあります。 SQLだけ知りたい方は、下部にある結論から読んでみてください。 → 下部にある結論に飛ぶ ■ はじめに MySQLで完全外部結合FULL OUTER JOINはまだ使えません。 ですので、同じ結果を得る別の方法を考える必要があります。 なお基礎知識は本当に基礎的なことなので、読み飛ばしていただいても大丈夫です。 ■ 基礎知識 まず結合について、次の2テーブルを考えます。 テーブルA (table_a) user_id user_name
SQL の基礎 – JOIN (表結合)の意味の違い|てくめも@ecoop.net
MySQL / PostgreSQL / Oracle すべてのSQLサーバで基準になっているSQL標準のJOIN(LEFT JOINなど)について、基礎からしっかりまとめてみました。 ■目次 JOINの種類 ON, USING, NATURALによる結合条件指定 複数のJOIN句を組み合わせる 参考リンク ■JOINの種類 SQL 標準では JOIN 句による結合構文は次のような種類があります。 INNER JOIN LEFT OUTER JOIN RIGHT OUTER JOIN CROSS JOIN LEFT JOIN, RIGHT JOIN など、よく使われる構文は上記の省略形です。 ・ただの JOIN は INNER JOIN の省略形。 ・LEFT JOIN は LEFT OUTER JOIN の省略形。 ・RIGHT JOIN は RIGHT OUTER JOIN の省略形。
【SQL】相関サブクエリ入門 - Qiita
相関サブクエリとはサブクエリの一種であり、外側のクエリの値をサブクエリ内で使用する。 相関サブクエリを使用したSQLはややこしくて読みにくい場合が多いが、基本形を１つおさえておくとだいぶ理解しやすくなる。 サブクエリが何かわからない場合は、こちらを先に読んで欲しい。 http://qiita.com/mokrai/items/6df0513ccc5aa40a075a 動作確認環境とテーブル PostgreSQL 9.4でクエリの動作を確認した。 また、使用したテーブルの定義は下記。 CREATE TABLE Employees ( id INTEGER PRIMARY KEY, name VARCHAR(10) NOT NULL, age INTEGER NOT NULL, department VARCHAR(10) NOT NULL ); INSERT INTO Employees V
SQLスタイルガイド - Qiita
はじめに 本文書はSQLのスタイルガイドです。 PythonやRubyのようなプログラミング言語には有名なスタイルガイドがあり、共通のレイアウトルールに沿ったインデントや命名規則に則ったコードが生み出されています。 一方、SQLには知名度のある統一されたスタイルガイドがありません。 そのため、思いのままに書かれたSQLが散見されます。 もちろん、SQLを使ってアドホックな分析を行う場合は、必ずしもルールに沿う必要はなく、効率よく書いても良いと思います。 しかし、Webサービスやバッチの中に組み込むようなもの、つまり自分以外の誰かに読まれるSQLは、多くのプログラミング言語同様に何らかのスタイルガイドに沿うことで多くのメリットを享受できると思います。 クエリが構造化され、可読性が高まる バグの発見や修正が容易になる 改行位置やインデントなどのフォーマットの悩みが解消される スタイルガイドを共
Railsのデータロック - Qiita
begin ActiveRecord::Base.transaction do . . raise 'ロールバックします' end p 'コミット' # トランザクション処理を確定 rescue => e p 'ロールバック' # トランザクション処理を戻す end transactionブロックの中で登録・更新処理を行う場合は、saveやupdateではなく、save!, update!を使用する。 transactionブロックの中で複数のモデルの更新を行った後に例外を発生させると、全部のモデルがロールバックする。 楽観的ロック 「競合は多分起きないだろう」という前提で、データの取得時には何もせず、更新時に競合をチェックする方法。 レコードのバージョン管理を行うため、テーブルにlock_versionカラムを追加する。その際、デフォルト値を0にする。 lock_versionはレコード
登録不要、インストール不要、フリーなブラウザ上でSQLの練習問題を解ける「SQL Bolt」を試してみよう - Qiita
登録不要、インストール不要、フリーなブラウザ上でSQLの練習問題を解ける「SQL Bolt」を試してみようSQL初心者向けSQLBolt SQL初心者向けです。わかりそうでわからなかったSQL文を実戦形式で勉強できる素材を探していました。Paizaの記事（下記参照）で紹介されていたSQL Boltを試してみました。 初心者向け・SQLの練習問題をたくさん解ける学習サイトと本7選 http://paiza.hatenablog.com/entry/2018/01/22/%E5%88%9D%E5%BF%83%E8%80%85%E5%90%91%E3%81%91%E3%83%BBSQL%E3%81%AE%E7%B7%B4%E7%BF%92%E5%95%8F%E9%A1%8C%E3%82%92%E3%81%9F%E3%81%8F%E3%81%95%E3%82%93%E8%A7%A3%E3%81%9
えっ、まだPostgreSQLでダブルクォーテーション使ってるの？ - Qiita
するとこれ、エラーで返ってきました。 （エラーメッセージはうろ覚えですが「value1なんてカラムは存在しないよ」的なことを言ってました） PostgreSQLでは、ダブルクォーテーション「”」をシングルクォーテーション「'」にしないといけません。なので、以下のように変更します。 「”」と「’」の違い PostgreSQLなどの標準SQLでは、 シングルクォーテーションで囲う：文字列定数として扱う ダブルクォーテーションで囲う：カラム名として扱う という仕様になっている。 'value1'はvalue1という文字列として捉え、"value1"はvalue1というカラムの名前として捉えられます。 テーブルになにか文字列を挿入するときはシングルクォーテーションで囲ってやらないと、SQLが文字列として認識してくれないわけです。 つまり、文字列定数をダブルクォーテーションで囲うな！ということです。
データベース用語和英対応表 - Weblog on mebius.tokaichiba.jp
6～7年前に買ったSQLの入門書を、捨てる前に読み返している。この入門書を使って1回SQLを勉強したのだが、実際に使うことが無かったため、全く身に付かず、歳のせいで記憶にも残っていないのだ。実際、MySQLを触りながら復習しようとして、mysqlを起動すると、"select * from （テーブル名）;"以外の文はそらでは全く書けなかった。 従って、SQLの入門書とMySQLのマニュアル(MySQL info)とを見ながらSQLを試しているのだが、SQLの入門書が日本語でMySQLのマニュアルが英語であり、筆者にデータベースの基礎知識がないため、日本語と英語の対応が取れない用語がいくつか発生した。 そこで、出くわしたデータベース用語の日本語と英語の対応表を作ることにした。 日本語英語
[SQL Server]WITH句で共通テーブル（CTE式）を使用する
共通テーブル（CTE式）の使い方 共通テーブルを使うメリット ソースの可読性を向上する 同じテーブルの副問い合わせや、同じテーブルの結合など。 SQLの冗長化を防ぎ、ソースを見やすくすることができる。 テーブルの結合前に行数を減らしておくことができる 行数の多いテーブル同士を結合すると、結合条件式の処理にも時間がかかり、クエリのパフォーマンスも低下する。 共通テーブル式（CTE式）の内部で条件を絞り込めば、行数を減らすことができ、クエリのパフォーマンスも向上する。 共通テーブル式の記述方法 共通テーブル式は下記の通り、WITH句を用いて記述する。 -- パラメータ（検索条件） DECLARE @PlantCode varchar(max) = 'Tokyo' ,@DateFrom datetime = '2017/01/01' ,@DateTo datetime = '2017/01/07
![[SQL Server]WITH句で共通テーブル（CTE式）を使用する](https://cdn-ak-scissors.b.st-hatena.com/image/square/3cd5e3f1b61254443cd89a571b306d6e754eefb5/height=288;version=1;width=512/http%3A%2F%2Fblog.itparadise.jp%2Fwp-content%2Fuploads%2F2017%2F07%2Fdigit01.jpg)
[Redshift][PostgreSQL] WITH句を使ってSQLをシンプルに。 | DevelopersIO
環境 MAC OSX 10.10.5 Yosemite 使い方（例） テーブルの準備 CREATE TABLE items ( id SMALLINT , name VARCHAR(16) , item_id SMALLINT , item_name VARCHAR(16) , PRIMARY KEY(id, item_id) ); INSERT INTO items VALUES (1, '文房具', 1, 'シャーペン') , (1, '文房具', 2, '消しゴム') , (1, '文房具', 3, '定規') , (2, 'かばん', 1, 'リュックサック') , (2, 'かばん', 2, 'ショルダーバッグ'); CREATE TABLE genre ( id SMALLINT , name VARCHAR(16) ,PRIMARY KEY(id) ); # SELECT *
![[Redshift][PostgreSQL] WITH句を使ってSQLをシンプルに。 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/6f1fde3cff7767965729d2d96d3e31da5b8a643d/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2018%2F11%2Feyecatch_developers.io_1200x630.jpeg)
Rails: 闇雲にインデックスを付けてはいけない（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Don't index the kitchen sink! 原文公開日: 2015/07/09 著者: Jeroen Weeink サイト: Crafting Ruby 最近、使われてないインデックスを外す作業を行ってたのですが、やってみると出るわ出るわ。そのほとんどは、逆関連付けの不要なモデルのJOINの一部でした。次の例で考えてみましょう。 class ShoppingCart < ActiveRecord::Base has_many :shopping_cart_products has_many :products, through: :shopping_cart_products end class ShoppingCartProduct < ActiveRecord::Base belongs_to :shoppin
Railsエンジニアなら知っておきたい！RDBでindex作成を検討するときってどんなとき？ - Qiita
はじめに 前回に引き続き、またまたDBネタです(^o^) 前回：Railsエンジニアなら最低限これだけは知っておきたいSQLのJOINの動き 今回は、インデックスについてです。インデックスにはいくつか種類がありますが、 RDBで一般的に使われるB-treeインデックスについて書いていきます。 いきなりですが、インデックスは深い！かなり深い！バイカル湖くらい深いです。 ある程度の指針的なものはありますが、インデックスをどう設計するかの見極めは状況によって変わってくるようです。クエリの実行頻度、テーブルサイズ、カーディナリティ（カラム内のデータの種類の多さ）などなど。。 なので今回は、こんなときはインデックス作成を検討した方がいいというパターンだけザッとまとめる感じで行きたいと思います。 なお、今回の記事作成にあたっては、以下の本を参考にさせて頂きました。 そもそも的なところから分かりやすく書
これでわかった!? LEFT / RIGHT JOIN. - Qiita
drop table if exists depts; create table depts( dept_id int primary key, dept_name varchar(32) ); insert into depts(dept_id,dept_name) values(1,'営業部'); insert into depts(dept_id,dept_name) values(2,'経理部'); insert into depts(dept_id,dept_name) values(3,'技術部'); insert into depts(dept_id,dept_name) values(4,'法務部'); #employees drop table if exists employees; create table employees( id int primary key
index の複数形は indexes なのか indices なのか - 猫でもわかるWebプログラミングと副業
プログラマーが覚えておきたい英単語(http://blog.livedoor.jp/lalha/archives/50165797.html)によると インデックスを表す単語の index の複数形についての表現。普通に複数形にすると indexes になりそうなものだが、公開されている API などを見ていると、indices が使われていることが多い。英英辞典などを見ると、indexes も indices も載っているので、両方とも間違いではないと思われる。 とある。 一方で、『SQLアンチパターン』では、 データベース関連の用語として用いられる場合、indexは順番に並べられた情報の集合を意味します。この場合のindexの望ましい複数形はindexesです。他の文脈では、indexはindicatorを意味することがあり、この場合の複数形はindicesです。 とある。 Webli
Rails: JOINすべきかどうか、それが問題だ — #includesの振舞いを理解する（翻訳）
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: To join or not to join? An act of #includes 原文 公開日: 2017/08/07 著者: Tiago Farias 原文ではシェークスピアの古典劇『ハムレット』のセリフが多数引用されています。引用されたセリフのリンクをマウスオーバーするとシェークスピアの原文がポップアップします。 actの基本的な意味は「演技（する）」「（舞台の）場面」であり、タイトルはこれにかかっています。 2017/09/25: 初版公開 2021/09/22: 更新 訳注 k0kubunさんの以下の記事も合わせて読むことをおすすめします。Rails 5以降は#left_outer_joins（またはエイリアスの#left_joins)が使えます。また、#includesがActiveRecord::Baseを生成す
ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 | Webシステム開発／教育ソリューションのタイムインターメディア
ActiveRecord4でこんなSQLクエリどう書くの？ Merge編 #activerecord#rails#ruby 2013年 10月 24日 nishio 「このデータ取得するのにSQLではこういう風に書けばいいんだけど、ActiveRecordでは一体どう書けばいいの？」 毎回この課題に悩まされています。 特に業務アプリの場合、とてつもなく複雑なSQLを投げる場合があります。 ものすごい数のテーブルをjoinして、existsで条件みて、union allして。。。 なんていう処理がでてくると、さすがにActiveRecordやDatamapperを使ってクエリを組み立てるのをあきらめて、直接SQLを書いてしまうことがあります。 でも、できればActiveRecordを使ってスマートにSQLを組み立てたいものです。 scopeで書いておけば、処理も使い回せますしね。 ということ
SQL文を最速にする11のポイント たとえ最終的な結果が同じでも，SQL文は書き方一つでパフォーマンスがずいぶんと変わってきます。ここでは，速いSQL文を記述するためのポイントや注意点をいくつか紹介しておきましょう。 ●WHEREの左辺で算術演算子や関数を使わない WHERE句の左辺に算術演算や関数を指定すると，インデックスが使われません。例えば， SELECT NAME FROM CUSTOMERS WHERE SAL - TAX ＞ 1000 とすると，たとえSALフィールドにインデックスが定義さ
“ SQL文を最速にする11のポイント たとえ最終的な結果が同じでも，SQL文は書き方一つでパフォーマンスがずいぶんと変わってきます。ここでは，速いSQL文を記述するためのポイントや注意点をいくつか紹介しておきましょう。 ●WHEREの左辺で算術演算子や関数を使わない WHERE句の左辺に算術演算や関数を指定すると，インデックスが使われません。例えば， SELECT NAME FROM CUSTOMERS WHERE SAL - TAX ＞ 1000 とすると，たとえSALフィールドにインデックスが定義されていてもテーブル全体を走査してしまいます。こうした場合は， SELECT NAME FROM CUSTOMERS WHERE SAL ＞ TAX + 1000 のように記述すれば良いでしょう。 ●「後方一致」検索はなるべく避ける インデックスが付加されているフィールドであっても，LIKE
INとEXISTSの違い - SQLer 生島勘富 のブログ
INとEXISTSは違います。 BETWEENと、不等号の組合わせなど、等価になる記述法はあるのですけれど、INとEXISTSは基本的に同じ結果を返すことが可能ですが、意味は違います。 この違いが分かるにはインデックスを理解する必要がありますので、まずは、インデックスのイメージをつけてください。 まずはイメージ ここでも、まずはイメージで考えましょうね。 あなたは先輩の結婚式の司会を頼まれましたとします。イロイロと準備がありますが、余興で歌を歌う人がいるとき、予めカラオケの番号を調べておくでしょう。 食事の間のBGMについては、ラブソングの入ったiPodをつないでランダムで流すことにしましょう。しかし、新郎新婦にとって（過去の恋愛経験上）都合の悪い曲があり、チェックしてはじいておくことにしました（なかなか、そつがない司会ですな）。 これらの処理をSQLにするならば……。 ■カラオケの番号を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
.gitattibutes seems to be ignored for 'sql' language · Issue #3666 · github-linguist/linguist
doruby.jp
