タグ

sqlに関するtakaesuのブックマーク (30)

  • Arctype SQL Client

    Build beautiful charts in 2 clicks. Combine multiple charts in a Dashboard.

    Arctype SQL Client
  • あまり知られていないPostgreSQLの機能 | POSTD

    あなたが知らない既存機能があるかもしれません! マイクロソフト社は2006年、Microsoft Officeの新バージョンで追加してほしい機能について、顧客調査を実施しました。驚いたことに、ユーザが希望した機能の90%以上はすでに実装されており、その存在が知られていないだけであることが判明しました。機能の「見つけにくさ」の問題の解決策として同社が考案したのが、現在のMicrosoft Office製品でおなじみの「リボンUI」です。 この問題はOfficeに限ったものではありません。日々使用するツールの機能をすべて把握している人はほとんどいません。PostgreSQLのように大規模なツールであればなおさらです。数週間前にPostgreSQL 14がリリースされたばかりなので、この機会にPostgreSQLのあまり知られていない機能に注目してみたいと思います。 この記事では、Postgre

    あまり知られていないPostgreSQLの機能 | POSTD
  • MySQL 条件つきでCOUNT、SUM、AVGする | テクニカルノート

    SELECT分で、WHEREで条件を指定して取り出したデータを、COUNTしたり、SUM(合計)したり、AVG(平均)したりする方法。 まずは、サンプルデータを作ります。 CREATE TABLE test ( id BIGINT , name TEXT , age SMALLINT ) ; INSERT INTO test (id, name, age) VALUES ('1', 'nagatomo', '31'); INSERT INTO test (id, name, age) VALUES ('2', 'yoshida', '28'); INSERT INTO test (id, name, age) VALUES ('3', 'honda', '30'); INSERT INTO test (id, name, age) VALUES ('4', 'okazaki', '31')

    MySQL 条件つきでCOUNT、SUM、AVGする | テクニカルノート
  • makopi23のブログ 「外部キー Night」に参加しました

    2015/2/13(金) 「外部キー Night」に参加してきました。 connpass http://connpass.com/event/11463/ 場所は千駄ヶ谷(代々木)のピクシブ株式会社さんです。 参加者は60人くらいでしょうか。 ・・・この勉強会のタイトル!そしてピンポイントなテーマw 惹きつけられずにはいられない! そんな私も、SQLアンチパターン読書会で4章「キーレスエントリ」の紹介を担当したということもあり、外部キーには少し思い入れがある一人なのです。 外部キーNightのお供に、書籍「SQLアンチパターン」の4章、「キーレスエントリー」をお一つ、いかがですか~ / SQLアンチパターン読書会 「キーレスエントリー」 に参加しました http://t.co/Z116mYUDyI #sqlap #fk_night — makopi23 (@makopi23) 2015,

    makopi23のブログ 「外部キー Night」に参加しました
  • 【SQL】複数の条件のcountを1回のクエリでおこなう at softelメモ

    問題 こんなテーブル a があります。 create table a (id int, flag int); こんなふうにデータを入れて、 insert into a (id, flag) values (1, 1), (2, 1), (3, 0), (4, 0), (5, 1); こんなふうになっているとします。 select * from a; +----+------+ | id | flag | +----+------+ | 1 | 1 | | 2 | 1 | | 3 | 0 | | 4 | 0 | | 5 | 1 | +----+------+ なるべく単純な1つのSQLで、すべてのレコード数と、flag=1のレコード数と、flag=0のレコード数を取得せよ。 なお、サブクエリは使わないこと。 ヒント 集計を3つしたいので、こうなる? select count(????), c

    【SQL】複数の条件のcountを1回のクエリでおこなう at softelメモ
    takaesu
    takaesu 2020/05/21
    count をよしなに
  • なぜMySQLのサブクエリは遅いのか。

    よくMySQLはサブクエリが弱いと言われるが、これは当だろうか?半分は当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし

    なぜMySQLのサブクエリは遅いのか。
  • 検索条件をWHEREで指定する場合とJOIN ONで指定する場合の違い - HK's Weblog

    mysqlにおいてWHEREとJOIN ONで条件を指定した場合の違いがよくわかっていなかったのでまとめておく。 映画を表すmoviesテーブルと映画の日毎の再生回数を表すplaycountsテーブルがあるとする。 moviesテーブル +----+------------+ | id | title | +----+------------+ | 1 | MI3 | | 2 | Super Man | | 3 | Spider Man | +----+------------+ playcountsテーブル +----+-------+----------+------------+ | id | count | movie_id | date_at | +----+-------+----------+------------+ | 1 | 10 | 1 | 2012-12-16 |

    検索条件をWHEREで指定する場合とJOIN ONで指定する場合の違い - HK's Weblog
    takaesu
    takaesu 2019/04/04
  • インデックスを使うとなぜ速くなるのか

    インデックスを使うと何故早くなるのか ページではORACLEにおいてインデックスを使うと何故クエリが早くなるのか、またはなぜ速くならないのかを説明します。 なお、ページでは索引構成表やビットマップインデックス等の特殊なデータ構造を持つオブジェクトは考慮しておらず一般的なテーブルとインデックスを想定しています。 前提知識 インデックスを使うとなぜ速くなるのかを理解するためには以下の前提を理解している必要があります。 ・ディスクアクセスはCPUアクセスと比較すると非常に遅い 一般的にはCPU処理時間がナノ秒単位であるのに対してディスクのアクセス時間はミリ秒単位であり、ディスクはCPUに比べて100万倍程度処理が遅いとされています。 したがって、クエリの処理時間はディスクアクセスが最も少ない実行計画が最も高速となる可能性が高いと考えられます。 ・I/Oの単位はブロックである ORACLEのI

  • SQLのORDER BY で任意のソート順を設定する - Qiita

    ※追記 変換ツールを作りました。 https://yuyabu.github.io/OrderByWithCaseExpressionGenerator/ SQLのORDER BYでは昇順・降順で特定のカラム(単独or 組み合わせ)の並びを指定できるが、CASE式を組み合わせて、任意のソート順を指定出来ることを最近知った。 (SQL内だけでこういうことが実現できるのが衝撃的) WITH students as( SELECT 1 AS sid, '高橋太郎' AS sname FROM DUAL UNION ALL SELECT 2 AS sid, '山田幸助' AS sname FROM DUAL UNION ALL SELECT 3 AS sid, '鈴木美恵子' AS sname FROM DUAL UNION ALL SELECT 4 AS sid, '織田信長' AS sname

    SQLのORDER BY で任意のソート順を設定する - Qiita
    takaesu
    takaesu 2018/11/19
  • ISUCON8予選突破しました - あおうさ@日記

    予選突破 ISUCONというWebアプリケーションのパフォーマンス改善コンテストに参加し、予選突破しました。去年は不参加だったので2年振り2度目。(blog書くのもISUCON6振りで2年振りという... output無さすぎ) いやー実に楽しかった。やっぱりISUCONでしか味わえないモノがある。いつも何か新しい学びがある。 予選は両日共に問題なく進んだようですし、予選問題もいい問題でした。ベンチマーカーが詰まることもなく快適な予選でした。運営のみなさんありがとうございます。 久しぶりの参加だったので事前にISUCON7予選を解いてみたりconoha vpsでサーバ立ててansibleやfabric(deployに使っている)の動作確認をしたりして挑みました。ISUCON7予選を動かし始めたらあーこの感じやっぱり楽しいなと思って気持ちを高めてISUCON8に臨めて良かった。何を事前準備し

    ISUCON8予選突破しました - あおうさ@日記
    takaesu
    takaesu 2018/10/16
    SQL周りの解析参考になる
  • Arelでクエリを書くのはやめた方が良い5つの理由

    はじめに:Arelって何? みなさん、Arel(アレル)ってご存知ですか? ArelはActive Recordの内部で使用されるSQL生成ライブラリです。 Railsのクエリの書き方をググると、ときどきArelを使った実装例が見つかるので、見たことがある、もしくは何度か使ったことがある、という人もいると思います。 Arelをよく知らない人のために、Arelの利用例をちょっと見てみましょう。 たとえば「コメント文中に、"ruby"が含まれるユーザープロフィールを検索したい」という場合、Rails標準のクエリインターフェースを使うと条件部分のSQLを文字列で書く必要があります。(PostgreSQL環境を想定) Profile.where( "profiles.comment ILIKE ?", "%ruby%" ).to_sql #=> SELECT "profiles".* # FROM

    Arelでクエリを書くのはやめた方が良い5つの理由
  • MySQL Orderby a number, Nulls last

  • Rails SQL Injection Examples

    Overview The Ruby on Rails web framework provides a library called ActiveRecord which provides an abstraction for accessing databases. This page lists many query methods and options in ActiveRecord which do not sanitize raw SQL arguments and are not intended to be called with unsafe user input. Careless use of these methods can open up code to SQL Injection exploits. The examples here do not inclu

  • なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 - エンジニアHub|Webエンジニアのキャリアを考える!
  • 分析SQLのコーディングスタイル - クックパッド開発者ブログ

    SQL、書いてますか? こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……? という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし(青木)が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析

    分析SQLのコーディングスタイル - クックパッド開発者ブログ
  • クックパッド開発者ブログ

    こんにちは。機械学習グループの深澤(@fukkaa1225)です。 先日、Amazon Bedrock が一般利用できるよう(GA)になりました 。記事ではこちらを用いて RAG(Retrieval-augmented generation) アプリケーションを作成してみた様子と、他 LLM モデルとの比較結果についてご紹介します。 Amazon Bedrock とは aws.amazon.com 公式サイトより文言を引用します。 Amazon Bedrock は、Amazon や主要な AI スタートアップ企業が提供する基盤モデル (FM) を API を通じて利用できるようにする完全マネージド型サービスです。そのため、さまざまな FM から選択して、ユースケースに最も適したモデルを見つけることができます。Amazon Bedrock のサーバーレスエクスペリエンスにより、すぐに FM

    クックパッド開発者ブログ
  • DELETE_FLAG を付ける前に確認したいこと。 - Qiita

    DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか?」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計

    DELETE_FLAG を付ける前に確認したいこと。 - Qiita
  • 階層構造データへの挑戦 - Qiita

    <この記事は「Money Forward Advent Calendar 2015」の8日目の記事です> みなさんSQL書いてますか? 今回は、RDBSQLを使って階層構造データをうまく扱う(ことに挑戦しようとする)方法に関するお話です。 数年前に出た「SQLアンチパターン」というに書かれている内容で、大勢の方の記事でも取り上げられている話なのでだいぶ今更感が強いですが、私自身の忘備録としてまとめました。 というのも、実は私はこの記事の後半に書いた内容を使ってとあるシステムを設計していたのですが、諸事情あって結局そのシステムは日の目を見ずにお蔵入りになり、そのための供養を兼ねていたりもします。 身近な例で言えば、ファイルシステムのディレクトリ構造がまさに階層構造になっていますね。 このような階層の概念は、いろいろなところで出てくるもので、なんらかのシステムを作る際には大なり小なり関わっ

    階層構造データへの挑戦 - Qiita
    takaesu
    takaesu 2016/02/02
    パスでの階層以外にクロージャテーブル(clousure table)を用いた方法
  • #ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ

    名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる!! 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる

    #ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
  • サービス終了のお知らせ

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

    takaesu
    takaesu 2015/08/14