こんにちは。ディレクターの川原田です。 クックパッドでお気に入りレシピを保存する「MYフォルダ」のサービス開発や、保存・記録に関する新規サービスの検討・開発を担当しています。 ディレクターの仕事は様々ありますが、今回は私が身につけたことで仕事領域が広がった！と感じているSQLについてお話ししたいと思います。 いきなりですが、SQLが使えてよかった点をまとめると以下です。 よかったこと 数値抽出から分析まで自己完結 エンジニアとのコミュニケーションがスムーズに 仕事が増えていそうで実は効率アップ 周囲の知的好奇心を刺激 それぞれ具体例を交えてお話します。 数値抽出から分析まで自己完結 事例１：ログ構造を理解でき後の仕事がスムーズに 昨年、アプリのサービス開発を担当した際、エンジニアの設定したログが、実際に送信されるかどうかを事前チェックをしました*1。 アプリのリリースはタイミングが決められ
まぁ、言うほど大げさな話でもないのだけど、少なくとも、結合条件と検索条件の違いが分かっていないと痛い目見るだろう、と。条件なんてON句に書いてもWHERE句に書いても一緒でしょ、と思っている人(誰)は要注意。 前提とするテーブルは次の2つ。(諸般の事情で、purchase_dateが文字列型になっているが、今回はそこには触れない) CREATE TABLE product( product_code VARCHAR(16) NOT NULL , product_name VARCHAR(16) NOT NULL ) CREATE TABLE purchase( purchase_date VARCHAR(10) NOT NULL , product_code VARCHAR(16) NOT NULL , purchase_count INT NOT NULL ) それぞれデータは以下のよう
最近、SQL文を直接書く機会があって、今までほとんど全くSQLについて勉強する機会がなかったので業務に関係のあるところを少しかじってみることに。 今までいかにActiveRecord先生にお世話になっていたかがよくわかりました。 さてさて、それでは本題。 INNER JOINとOUTER JOINの違いについて理解を深めていきます。 以下のテーブルに対してSQLを発行してその結果を見ていくことにします。 mysql> select * from dogs; +----+-------+----------+ | id | name | owner_id | +----+-------+----------+ | 1 | aka | 1 | | 2 | ao | 2 | | 3 | shiro | 1 | | 4 | kuro | 4 | +----+-------+----------+
SQLの JOIN って。 用語がたくさんあって分かりにくいですね。 しかし覚えれば良いのは、実は次の三つだけ です。（本当です） JOIN RIGHT JOIN LEFT JOIN これ以外のことは 考えなくて大丈夫 です。 なぜなら、あとはすべて この三つの別名 に過ぎないからです。 分類 INNER JOIN はなんと、1種類だけです。 (驚きましたか？) OUTER JOIN は2種類あります。 そして LEFT と RIGHT に分かれます。 JOIN とは 「内部結合」です。 「結合できなかった行」は返しません。 本当の名前は INNER JOIN といいます。 でもそのことは、今は話さなくても良いでしょう。 JOIN はシャイで、優しすぎる。そして世間知らずです。 JOIN には、外の世界のことが分からないのです。 しかしこの世界にひとつしか存在しない、かけがえのないものが
概要 Amazon Aurora 事例祭りの事例紹介ということで、1年ほど前にクラブレコチョクのシステムをOracle RACからAmazon Auroraへ移行したので、それについてお話しさせていただきました。 内容 こちらが発表のスライドになります。 アジェンダとしては、 レコチョクとクラブレコチョクについて Auroraを選択した理由 どのようにAuroraへ移行したか どのようにAuroraを運用しているか Auroraに期待するところ といった感じでお話しさせていただきました。 レコチョクとクラブレコチョクについて スライドを参照いただければと思います。 Auroraを選択した理由 システム単体の課題を可決するために移行したというより、 会社全体としていくつか課題を抱えていたので、それを解決するために 全システムAWS移行を決めたというのが、まずはじめにあります。 Auroraを
ORM使ってて、便利で余裕キメてたらn+1問題を起こしてた。 n+1問題とは 1回目 のselectで、あるテーブルのレコードの集合を取ってきて、更にまた別のテーブルから先ほど取得したレコードデータ使用して n回 selectクエリを発行してしまう現象だ。 うまく説明出来ないので下の具体例書いてみた 解決策(今回の事案の場合) JOIN使ってクエリを一回にまとめる WHERE IN使ってクエリを2回にまとめる のどちらかの対処でクエリ減らす努力をするべきだった。 具体的にどうやってしまったか friendテーブルからplayerのフレンドのレコードの集合を1回引っ張ってきて、そのレコードからまたplayerテーブルへ、フレンドのplayerデータをn回取りに行っている。 sub _get_friends_info { # 自分のフレンド関係データ(player, target)のレコードの
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include: 1. @mosa_siru is an engineer at DeNA and CTO of Gunosy. 2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway. 3. Challenges discussed were managing 30 microservices, ensur
mongoコマンドから接続した際にオールドタイプ(SQL脳)たる我々人類にも 調べやすい形でinsert、select、updateを行う方法を調べました。 定義参照 // use [データベース名] use [データベース名] // show databases show dbs // show tables show collections参照系 // select * from [コレクション名] db.[コレクション名].find() // select * from [コレクション名] where x=4 db.[コレクション名].find({x:4}) // select j from [コレクション名] where x=4 db.[コレクション名].find({x:4}, {j:1}) // select * from [コレクション名] limit 1 db.[コレクション
既に紹介したように、WHERE句を使っても条件を指定してレコードを絞り込めます。HAVING句との違いを知っておきましょう。 HAVING句はGROUP BY句の後ろに記述しましたが、WHERE句はGROUP BY句の前（FROM句の直後）に記述します。記述位置を間違えると正しいSQLとは見なされないので、注意しましょう。 SELECT 商品名, 金額 ,性別 FROM 累積売上_fx WHERE 性別='女' GROUP BY 商品名, 金額, 性別 実行結果は先のHAVING句を用いたものとまったく同じです。 HAVING句とWHERE句、どちらを使っても同じ結果が得られました。どこが異なるのか、両者の違いを知っておきましょう。 HAVING句はGROUP BY句と共に用いますが、WHERE句にはそういった制限はありません。それぞれの記述位置も異なっています。このことが、２つの抽出命令
How to Select the First/Least/Max Row per Group in SQL Published Dec 7, 2006 by Baron Schwartz in Databases at https://www.xaprb.com/blog/2006/12/07/how-to-select-the-firstleastmax-row-per-group-in-sql/ Here are some common SQL problems, all of which have related solutions: how do I find the most recent log entry for each program? How do I find the most popular item from each category? How do I fi
テーブルのJOINが苦手でしたが、この例を思いついてからは、すっきりくっきり理解できるようになりました。むしろ頭から離れません……。 ※ INNER、OUTERは飾り。省略できる。 INNER JOIN → JOIN LEFT OUTER JOIN → LEFT JOIN RIGHT OUTER JOIN → RIGHT JOIN ※ ON ...=... をまとめて USING(属性) と書ける。 ※ 何で結合するか言うまでもない時は、NATURALを指定すると勝手にJOINしてくれる。NATURALにJOINして……。 ※ WHEREは結合した結果に作用する。 ※ 現実には上図のように1対1で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く