タグ

SQLに関するurza358のブックマーク (27)

  • リレーショナル・データベースの世界

    序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記:その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み

  • B-treeインデックス入門 - Qiita

    B-treeがMySQLで使用されている背景から、B-treeインデックスの構造、そしてそれに基づいたインデックスの使用方法の入門編です。以下の流れに沿ってまとめていきます。 インデックスってなに? B-treeってなんでインデックスに使われているの? B-treeインデックスの構造 インデックスの使用方法 ※ 勉強をかねてまとめていることもあり、間違っている箇所がございましたら教えていただけると嬉しいです。 インデックスってなに? 全体の内容の中から特定部分を探すために使用する、の索引のような概念のことです。これを用いることで、検索を高速化することができます。 特定の項目がのどこに載っているかを確認するために索引を調べることで、全ページを順に調べなくても、その項目が登場するページ番号がわかる MySQLのストレージエンジンでも、インデックスが同様の方法で利用されており、インデックスの

    B-treeインデックス入門 - Qiita
  • SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita

    2020/9/30追記 記事は元々、「SQL記述者全員が理解すべきSELECT文の実行順序のお話」というタイトルで投稿しておりました。 しかし、知見のある方からのコメントと自分でも調べてみた結果、今回紹介している順序はあくまで論理的な処理順序であり、実行順序とは別物ということがわかりました。 誤った知識を布教してしまい申し訳ございません。 2020/9/30のタイミングで、記事のタイトルを「SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話」に変更させていただきました。 はじめに 「SQLといえば、エンジニアが扱うスキル」と思われがちですが、最近はマーケターや営業など、非エンジニアの方もSQLを使って、自らデータを抽出し分析する方が増えてきています。 またエンジニアの方でも、ORM任せでなんとなく理解している状態の方もいるのではないでしょうか? 今回は、そんな方々にこそ

    SQL記述者全員が理解すべきSELECT文の論理的な処理順序のお話 - Qiita
  • 段階的に理解する O/R マッピング - Qiita

    はじめに O/R マッピングとは O/R マッピングとは、一言で言えば、オブジェクト指向プログラミング言語においてリレーショナルデータベースのレコードを通常のオブジェクトとして操作する方法である。より詳細な定義を述べるより、実際のコードを見たほうがわかりやすいだろう。以下に、低レベルの JDBC API の利用例と、高レベルの O/R マッピングフレームワークの代表格である JPA の利用例を挙げる。 public List<Issue> findByProjectId(long projectId) { String query = "select id, title, description from issue where project_id = ?"; try (PreparedStatement ps = connection.prepareStatement(query))

    段階的に理解する O/R マッピング - Qiita
  • Webアプリ作成 Spring Boot④DBからデータ取得(DAOパターン) - itmaroro Blog

    一覧画面にDBからデータを取得し、その値を表示するということをゴールに行っていきます。 今後DBの中身を確認したりデータ作成したりは「TablePlus」というツールを使用して実施していきます。 使い方や設定方法以下を参考にしてみてください。

    Webアプリ作成 Spring Boot④DBからデータ取得(DAOパターン) - itmaroro Blog
  • Amazon Timestream のよくあるクエリパターンとその効率的な SQL 記述方法 | Amazon Web Services

    Amazon Web Services ブログ Amazon Timestream のよくあるクエリパターンとその効率的な SQL 記述方法 Amazon Timestream は時系列データを取り扱う為のサーバーレスの目的別データベースサービスであり、その使用量に応じて課金が行われます。時系列データに対して、SQL を利用してクエリを実行しますが、同じ結果を得る為に複数の SQL 記述方法があり、そのパフォーマンスやコスト、複雑さはそれぞれ異なる為、正しいクエリを特定する事はとても重要です。また、組み込みの時系列関数を利用する事でクエリの複雑さを軽減する事ができます。 この投稿では、時系列のワークロードで一般的なクエリパターンと、それに対する Timestream の SQL クエリの効果的な記述方法を取り上げます。初めに投稿で利用する IoT のデータセットを確認し、次に、Times

    Amazon Timestream のよくあるクエリパターンとその効率的な SQL 記述方法 | Amazon Web Services
  • MySQL JOIN Types Poster - Steve Stedman

    So many times I have been asked for help with a query, where the question really comes down to the understanding of the difference between INNER and LEFT or RIGHT JOINs. I created this poster a few years ago and I keep it posted on the wall at the office. This way when I am trying to explain JOIN types, I just refer to the poster. I have created the poster below to help describe JOIN types in My S

    MySQL JOIN Types Poster - Steve Stedman
  • RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita

    "Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に

    RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
    urza358
    urza358 2022/12/08
  • TRUNC(日付) - オラクル・Oracle SQL 関数リファレンス

    TRUNC(日時) 関数の内容 切り捨てを行なう日時式 datetime を 切り捨てする時間の要素 format (省略時 DD) で切り捨てた値を戻す。 注意 TRUNC で使用される datetime の型は DATE 型であるため、TIMESTAMP 型を使用すると DATE 型に 暗黙変換 される。また DATE 型の精度のため秒単位での切り捨ては用意されていない。(Oracle 10g R2 時点) 週の初めの日の定義 切り捨てする時間の要素 format の 'DAY' 指定は週初めの日を戻すが週初めは NLS_TERITORY パラメータによって変わる。 NLS_TERITORY = Japan における週の初めは日曜日に定義されている。 TRUNC(日時) 使用例 SQL> select dt, fmt, TRUNC(dt, fmt) from trunc_date_sa

    urza358
    urza358 2022/10/11
  • Use Python SQLAlchemy ORM to interact with an Amazon Aurora database from a serverless application | Amazon Web Services

    AWS Database Blog Use Python SQLAlchemy ORM to interact with an Amazon Aurora database from a serverless application As organizations work to modernize their traditional applications to an event-driven, serverless model, a question that comes up frequently is how the object-relational mapping (ORM) layer should be managed. Packaging it with AWS Lambda functions increases its size and adds a cognit

    Use Python SQLAlchemy ORM to interact with an Amazon Aurora database from a serverless application | Amazon Web Services
  • 【資料&動画公開】AWSで実践!ビジネスを変革するデータ活用ソリューション | Amazon Web Services

    Amazon Web Services ブログ 【資料&動画公開】AWSで実践!ビジネスを変革するデータ活用ソリューション 2021年3月25日に「AWSで実践!ビジネスを変革するデータ活用ソリューション 」というイベントを実施しました。蓄積されたデータをこれから活用されようとお考えの方向けのセミナーで、特に「簡単に始めていただける」という点にフォーカスして、AWSのソリューションアーキテクトよりご説明しましたた。 今回このセミナーの資料や動画が公開になりましたので、以下で紹介します。 気軽にはじめるデータ可視化と機械学習による分析(講師:アマゾンウェブサービスジャパン株式会社 アナリティクス ソリューションアーキテクト 下佐粉 昭) セッションでは、可視化ソリューションにフォーカスし、可視化のメリットやそれを実現する課題を整理した後、Amaozon QuickSightによって、どのよ

    【資料&動画公開】AWSで実践!ビジネスを変革するデータ活用ソリューション | Amazon Web Services
  • BigQuery SQL でレイトレーシング - Qiita

    # 以降はコメントなのでこれは valid な pnm フォーマットです。 拡張子 pgm で保存すれば、Windows の場合は IfranView、macOS の場合は Preview.app で表示できます。 これで BigQuery で画像を出力できることが確認できました。 BigQuery によるレイトレーシング というわけで、BigQueryでレイトレーシングをやってみましょう。 実際のSQLコードは以下のようになります。 -- Vec3のドット積 CREATE TEMPORARY FUNCTION DOT (a STRUCT<x FLOAT64, y FLOAT64, z FLOAT64>, b STRUCT<x FLOAT64, y FLOAT64, z FLOAT64>) AS ( a.x*b.x + a.y*b.y + a.z*b.z ) ; -- 線形結合 aP +

    BigQuery SQL でレイトレーシング - Qiita
  • データベースを遅くするための8つの方法

    はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが1時間越えに化けることもザラにあるので原

    データベースを遅くするための8つの方法
    urza358
    urza358 2020/11/16
  • NoSQLは「一貫性あるトランザクションを実現できない」という誤解

    NoSQLは「一貫性あるトランザクションを実現できない」という誤解:NoSQLベストプラクティス(7)(1/3 ページ) 連載では、「NoSQLデータベースの今」を正しく理解し、ビジネス躍進の実現に向けた対策としての「ベストプラクティス」を掲示していきます。今回は、「NoSQLデータベースでは、トランザクションの一貫性を保証できない」という誤解について解説します。 NoSQLベストプラクティス 今回は、NoSQLにおける「データベースの一貫性」について説明し、よくある誤解を解消したいと思います。まず、「データベースの一貫性」の2つの種類「完全一貫性(guaranteed consistency)」と「結果整合性(eventual consistency)」について定義しておきます。 完全一貫性とは 「完全一貫性」は、ACID準拠のトランザクションエンジンに基づいています。ACIDは、「A

    NoSQLは「一貫性あるトランザクションを実現できない」という誤解
  • CSVのためのSQLライクなクエリ言語 – csvq – を試してみた #csvq | DevelopersIO

    今朝方、CSVに対してSQLを実行できる「csvq」というライブラリを知りました。業務の関係で快適にCSVを操作する方法を求めていたこともあって、操作感等含めて試してみました。 mithrandie/csvq 特徴 関係するオプションも合わせて表記してみました。 標準のデリミタがコンマ--write-delimiter 出力先指定オプションがある --out 色つけできる --color 標準で罫線がついてる--format タイムゾーンの設定ができる --timezone 手軽に対話シェルとして実行できる Ambiguous Character を全角文字の幅で表示可能--east-asian-encoding ゼロ幅スペースを半角文字としてカウント--count-format-code 改行コードを指定可能--line-break CSVに対して各種操作を行う際に、あると助かるオプショ

    CSVのためのSQLライクなクエリ言語 – csvq – を試してみた #csvq | DevelopersIO
  • スケーラブルな分散SQLエンジン「Presto」の開発団体「Presto Software Foundation」が発足

    スケーラブルな分散SQLエンジンとして大規模データに対して高速なクエリを実現する「Presto」は、2013年にFacebookが公開したオープンソースソフトウェアです。 現在でもFacebookをはじめTwitter、Uber、Netflix、ウォルマートなどがデータ分析などに利用しているとされています。 そのPrestoの開発者たちが、Prestoの開発を促進する団体「Presto Software Foundation」の設立を発表しました。 設立を発表するブログには、Presto Software Foundationの役割を次のように説明しています。 The Presto Software Foundation is dedicated to preserving the vision of high quality, performant and dependable soft

    スケーラブルな分散SQLエンジン「Presto」の開発団体「Presto Software Foundation」が発足
  • SQLインジェクションのまとめ - No Programming, No Life

    当記事はSQLインジェクションのまとめ | Think Twiceに移転しました。

    SQLインジェクションのまとめ - No Programming, No Life
    urza358
    urza358 2018/07/18
  • SQLのSELECT文を、DjangoのQuerySet APIで書いてみた - メモ的な思考的な

    SQLのSELECT文をDjangoのQuerySet APIで書いてみた時のメモを残しておきます。 2015/9/6 追記 id:kkotyy さんのコメントを受けて、文中の.values()は省略しました。 参考:QuerySet API reference | Django documentation | Django なお、GitHubのコードはそのままにしてあります。実行結果はモデルオブジェクトよりも辞書のリストのほうが確認しやすいかなと考えているためです。 2015/9/6 追記ここまで 目次 環境 今回使用するModel fixtureによるデータの投入 SQL SELECT句 全列抽出 指定列抽出 WHERE句 通常 NOT AND OR 演算子 ORDER BY句 昇順 降順 GROUP BY句 全体の集約 行の集約 LIMIT句 LIMITのみ OFFSET付 Pyt

    SQLのSELECT文を、DjangoのQuerySet APIで書いてみた - メモ的な思考的な
  • SQLECTRON GUI - SQLECTRONのGUIフロントエンド

    コンソール上で簡易的なデータベース管理UIを提供するSQLECTRONですが、設定が残せるので様々なデータベースに繋ぐ際に便利です。SQLの実行インタフェースとしては最低限ですが、接続をまとめてくれるだけでも便利でしょう。 そんなSQLECTRONにGUIを追加するのがSQLECTRON GUIです。設定ファイルが共有できるのが利点です。 SQLECTRON GUIの使い方 データベース接続画面です。CUIで設定した情報がそのまま使えます。 左側にデータベース一覧。右側がSQL実行インタフェースになります。 テーブル構造も確認できます。 SQLを生成してくれる機能があり、結果も一覧表で確認できます。 SELECT/CREATE/UPDATE/DELETE文の生成ができます。 SQLECTRON GUIはCUI版のSQLECTRONをラッピングしているだけなので機能も変わりません。しかしデー

    SQLECTRON GUI - SQLECTRONのGUIフロントエンド
  • SQLで大量のテストデータ作成 - Qiita

    以前に SQLでテーブルデータの一括作成、複製 という記事を書いたのですがもう少しかみ砕いて、かつPostgreSQLにも対応した内容で書き直してみます。 RDBMSを利用したアプリケーションを開発していて数千件を超える大量のデータを作成する必要が発生した場合に知っておくと便利なテクニックの紹介です。なお、以下のようなケースを想定しています。 SQLのパフォーマンス検証のために大量のレコードが必要 1テーブルに100万件以上 動作検証・評価作業のためにテスト内容に準じたデータが一定数必要 1セット100件を100セット 事前準備 SELECT文の 直積(CROSS JOIN) を利用します。 事前に一定数のレコードを保持するテーブルが必要です。 ここでは sample というテーブルを作成して 直積(CROSS JOIN) のSELECT文に利用します。 MySQLとPostgreSQL

    SQLで大量のテストデータ作成 - Qiita