タグ

関連タグで絞り込む (6)

タグの絞り込みを解除

SQLに関するhokorobiのブックマーク (33)

  • 開発者のためのSQLパフォーマンスの全て

    前書き - インデックスの作成はなぜ開発者のタスクなのか インデックスの 内部構造 - インデックスは何に似ているか インデックス リーフノード - 二重連結リスト 検索 ツリー(Bツリー) - バランス木 遅いインデックス パートI - インデックスを遅くする2つの原因 where 句 - 検索のパフォーマンスを改善するためにインデックスを作成 等価 演算子 - 一致するキーの検索 プライマリキー - インデックスの使い方を確認 複合インデックス - 複数列に対するインデックス 遅いインデックス パートII - 前の問題点が再び 関数 - where句の 中での関数 大文字・小文字を区別する 検索 - UPPERと LOWER ユーザ定義 関数 - 関数インデックスの制限 インデックスの作り過ぎ - 冗長性の排除法 パラメータ化 クエリ - セキュリティとパフォーマンスのために 範囲 検

    開発者のためのSQLパフォーマンスの全て

  • SQLアンチパターン - 開発者を待ち受ける25の落とし穴

    押さえておきたい、PostgreSQL 13 の新機能!!（Open Source Conference 2021 Online/Hokkaido 発表資料）NTT DATA Technology & Innovation

    SQLアンチパターン - 開発者を待ち受ける25の落とし穴
    hokorobi
    hokorobi 2013/02/17
    やっぱりSQLアンチパターン面白そうだな～。
    リンク

  • 第6回　SQLで木構造を扱う～入れ子区間モデル　（2）稠密性について | gihyo.jp

    稠密性（ちょうみつせい）について 前回から見えるように、整数から有理数へ範囲を広げることの利点は非常に大きいのですが、その理由は、有理数が整数にはない稠密性（ちょうみつせい：density）という性質を持っていることにあります。あまり日常で使う言葉ではありませんが、直感的に言えば物がぎっしり詰まっているということです。もう少し数学的に厳密に書くと、 x<yを満たす任意の数x、yについて、x<m<yとなる数mが存在する となります。平たく言えば、どんな2つの数の間（区間）にも、まだまだ無限に数がある、ということです。 ここでキーとなるのは「任意の」という言葉です。特定のx, yではなく、大小関係を満たすあらゆる数のペアについて成立することがキモです。たとえば、1と2の間には、0.5という数が存在します。今度は1と0.5の間で見ても、0.25というさらに中間の数が存在します。後は同じ手順で、1

    第6回　SQLで木構造を扱う～入れ子区間モデル　（2）稠密性について | gihyo.jp
    hokorobi
    hokorobi 2012/05/02
    リンク

  • 第6回　SQLで木構造を扱う～入れ子区間モデル　（1）もしも無限の資源があったなら | gihyo.jp


    はじめに 前回では、入れ子集合モデルという、リレーショナルデータベースで木構造を扱うための新しい方法論を紹介しました。このモデルは、RDB、SQLと親和性の高い優れたものではあるのですが、挿入など更新時に、無関係のノードまで変更対象としなければならないのが大きな難点でした。 そこで今回は、上記の欠点を解消する進化版のモデルを紹介します。この方法を理解していく過程で、私たちはRDBと集合論の結び付きの深さを再確認することになります。 ふだんこの連載は、1回完結の読み切り形式なのですが、今回に限り、前号の内容を前提としています。未読の方は、前号を先に読むと理解が増すでしょう。 稼働環境 すべてのリレーショナルデータベース もしも無限の資源があったなら 座標に整数のみを使う場合の限界 入れ子集合モデルの大きな欠点は、ノードを挿入︵追加︶するときに、自分より﹁右側﹂にある無関係なノードをもっと右へ
    第6回　SQLで木構造を扱う～入れ子区間モデル　（1）もしも無限の資源があったなら | gihyo.jp
    hokorobi
    hokorobi 2012/05/02
    リンク

  • 第5回　SQLで木構造を扱う～入れ子集合モデル　（3）入れ子集合モデルにおける更新 | gihyo.jp

    入れ子集合モデルにおける更新 次に、木構造の更新を行う例として基本的な、ノードの挿入と削除を取り上げます。本当はもっと多くの処理を行う方法がありますが、紙幅の都合上、代表的なものだけを取り上げます。興味を持った方は、参考資料に挙げたテキストをご覧ください。 リーフを追加する 木にノードを追加するときは、リーフとして追加するのか、それとも親として追加するのかを決める必要があります。今回は、処理として簡単なリーフとして追加することを考えましょう。たとえば、部下を持たない猪狩氏（2,3）の配下に新たな部下、国見氏を追加することを考えます。 今、猪狩氏の直径は1しかないので、そのままだと部下を持てません。そこで、まずは猪狩氏の円を「広げる」ことを考えます。国見氏を追加するためには、猪狩氏の右端座標より右の円の座標を一律2だけ大きくすればよいことがわかります。これは、リスト6のUPDATE文で可能で

    第5回　SQLで木構造を扱う～入れ子集合モデル　（3）入れ子集合モデルにおける更新 | gihyo.jp
    hokorobi
    hokorobi 2012/05/02
    リンク

  • 第5回　SQLで木構造を扱う～入れ子集合モデル　（2）入れ子集合モデルにおける検索 | gihyo.jp

    入れ子集合モデルにおける検索 ルートとリーフを求める まず入れ子集合の検索で基本となる考え方を理解しましょう。それは「包含関係を調べる」ことです。 たとえば、ルート（ここで言う足立社長）とリーフ（猪狩、木島氏ら）を求めることを考えます。リーフの円は、自分の中に下位の円を一つも含まないという特性を持ちます。したがって、NOT EXISTSによって表現できます（リスト1、図5⁠）⁠。 リスト1　リーフの円を求める SELECT * FROM OrgChart Boss WHERE NOT EXISTS (SELECT * FROM OrgChart Workers WHERE Workers.lft > Boss.lft AND Workers.lft < Boss.rgt); 図5　リスト1の実行結果

    第5回　SQLで木構造を扱う～入れ子集合モデル　（2）入れ子集合モデルにおける検索 | gihyo.jp
    hokorobi
    hokorobi 2012/05/02
    リンク

  • 第5回　SQLで木構造を扱う～入れ子集合モデル　（1）入れ子集合モデルとは何か | gihyo.jp


    はじめに 木構造と呼ばれるデータ構造の一種があります。1つのルート︵根︶と呼ばれるノードを始点として、︵⁠通常︶複数のリーフ︵葉︶と呼ばれるノードまでを経路で結んでできるデータ構造です。その名のとおり自然界にある﹁木﹂の構造ですし、学校時代、確率の授業で樹状図を書いた経験のある人もいるでしょう。 この構造は、私たちの周囲にとてもたくさん存在します。家系図や組織図も木ですし、IT関連の例では、ヒープやRDBのインデックス、ディレクトリ︵フォルダ︶によるファイルシステムやXMLも木構造です。Webの掲示板でも、最初の書き込みをルートとしてそれに対してコメントがつけられ、そのコメントにまたコメントがつけられるというプロセスで木構造を形成します。ここでは1つの書き込みがノードになります。 このように、IT技術と木構造は切っても切れない関係にありますし、多くの分野で応用されてもいるのですが、実は長い
    第5回　SQLで木構造を扱う～入れ子集合モデル　（1）入れ子集合モデルとは何か | gihyo.jp
    hokorobi
    hokorobi 2012/05/02
    リンク

  • Redmineチケットの階層化の実装方法 - プログラマの思索

    Redmineチケットのテーブルissuesテーブルにlft, rgtというカラムがVer1.0からあって、何に使うのか分かっていなかったが、下記の記事を読んでようやく理解した。 ラフなメモ書き。 【元ネタ】 【Redmine】issuesテーブルのlft・rgtって？ | Roppi.net SQLアタマアカデミー：第5回　SQLで木構造を扱う～入れ子集合モデル　（1）入れ子集合モデルとは何か ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第5回　SQLで木構造を扱う～入れ子集合モデル　（2）入れ子集合モデルにおける検索 ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第5回　SQLで木構造を扱う～入れ子集合モデル　（3）入れ子集合モデルにおける更新 ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第6回　SQLで木構造を扱う～入れ子区間モデル　（1

    Redmineチケットの階層化の実装方法 - プログラマの思索
    hokorobi
    hokorobi 2012/05/02
    入れ子集合モデル使えるかな？　重なっている場合にはどう表すんだろう？　ちょっと読んでみよう。
    リンク

  • INとEXISTSの実行計画の違い 理想は泥臭いアーキテクト


    最近行った現場で見ました。何故か昔から(特にOracle界隈？)盲目的に﹁INよりEXISTSのほうが速い﹂という迷信があって、猫も杓子もみーんなEXISTSになっている現場があったりします。 ※以下はOracle10g相手にあれこれチューニングした経験を踏まえての記述ですが、大筋は他のDBでも変わらないと思います。INもEXISTSもそれぞれ、一概にどっちが良いと決まっている訳じゃないので、ケースバイケースでどっちを使うかちゃんと考えないといけません。 結論 ・INが適している場合とは→選択的述語が副問合せに有る ・EXISTSが適している場合とは→選択的述語が親問合せに有る 選択的述語なんてふにゃっとした単語がでてきたけど、要は副問合せ側で条件絞込みできる場合はIN、親問合せ側で条件絞込みできる場合はEXISTS(のほうが適している可能性が高い)てことです。 ※以下はOracle10
    hokorobi
    hokorobi 2012/04/09
    リンク

  • 第2回　冗長性症候群～条件分岐をUNIONで表現するなかれ | gihyo.jp


    ここはとある街の総合病院。 ここには通常の診療科のほかに、一風変わった診療科が存在する。 何軒もの病院をたらいまわしにされた、手の施しようのないSQLや、今すぐに改善が必要なSQLが担ぎ込まれる救命室である。 それがSQL緊急救命室、略してSER︵SQL Emergency Room⁠︶⁠。 そう、ここは国内でも唯一のプログラミング専門外来である。 ロバート救命室部長。腕の立つエンジニアだが、口が悪く性格はもっと悪い四十オヤジ。 ︵AM10:00 休憩室。ワイリーが机に向かって一人で何かしている︶ どってぃろーんどってぃろーん、ぽぽぽんぽーん、どってぃろーん…
    第2回　冗長性症候群～条件分岐をUNIONで表現するなかれ | gihyo.jp
    hokorobi
    hokorobi 2011/10/17
    リンク

  • 削除フラグのはなし

    Query Optimization with MySQL 5.7 and MariaDB 10: Even newer tricksJaime Crespo

    削除フラグのはなし
    hokorobi
    hokorobi 2011/08/10
    ON DELETE CASCADE とか知らなかった。安易に TRIGGER 使っちゃってる気がするな。
    リンク

  • SQuirreL SQL Client Home Page

    SQuirreL SQL is hosted at: and IDEs used by SQuirreL developers: SQuirreL's SQL editor is based on: RSyntaxTextArea Feature highlights of 4.7.1: Multiple Alias modification Code completion offers contains mode Timeout for SQL executions Object tree: Save and restore selected nodes Data compare to clipboard Search function for table cell data popup Edit toggle button on SQL result tabs Graph Plugin

  • OracleのPIVOT句 - プログラマの思索


    SQLで横持ちにデータを集計したい時に、PIVOT句を使うと便利だったのでメモ。 ︻元ネタ︼ Oracle 11g検証 隠れた新機能検証　その１｜おら!オラ!Oracle｜技術情報｜株式会社インサイトテクノロジー Oracle 11g R1新機能のPivotとUnPivot︵1/5︶‥CodeZine OracleのSCOTTスキーマにある従業員テーブルで、JOB(仕事)とDNAME(部門)ごとに集計したい場合、下記のSQLで書ける。 select emp.deptno,dname ,sum(decode(job,'CLERK' ,sal,null)) "CLERK" ,sum(decode(job,'MANAGER' ,sal,null)) "MANAGER" ,sum(decode(job,'PRESIDENT',sal,null)) "PRESIDENT" ,sum(decode
    OracleのPIVOT句 - プログラマの思索

  • IDEA * IDEA

    ドットインストール代表のライフハックブログ

    IDEA * IDEA
    hokorobi
    hokorobi 2011/01/08
    リンク

  • SQL の相関サブクエリ (4) - SELECT 句で使う

    「SQL の相関サブクエリ (3) - 量化された比較述語 ALL, ANY」 のつづき これまでは WHERE 句において相関サブクエリを利用する例を見た。今回は SELECT 句で使う。 前回と同じデータベースを対象にして 例えば、 性別ごとに年齢の順位 を求めたい。 SELECT 句で相関サブクエリ … とは言ったものの、いきなり書こうと思っても頭が混乱するのでゆっくりと。 まずは、「人」の属性に 「全体の人数」 を加えた結果を取得する。 select *, (select count(*) from persons) as num from persons as p1 結果は、 +----+---------+--------+-----+------+ | id | name | gender | age | num | +----+---------+--------+----

    SQL の相関サブクエリ (4) - SELECT 句で使う
    hokorobi
    hokorobi 2010/11/07
    リンク

  • SQL の相関サブクエリ (3) - 量化された比較述語 ALL, ANY


    SQL をはじめて触ったとき、exists 述語と並んで直感的に理解しずらかったのが ALL や ANY を伴った比較。 WHERE 句において単体の値を比較するのは問題ないけれど、 ﹁すべての XXXX と比べてどうか？﹂ とか、﹁少なくとも1つの XXXX と比べてどうなのか？﹂ となるとイメージしずらくなる。 量化 – Wikipedia によると、 全ての人間の言語は、完全な数体系がない場合でも、量化を利用している︵Wiese 2004︶。例えば、日本語での例は次の通りである。 ﹁全ての方針に目を通す必要がある﹂ ﹁川を渡っている人のうち何人かが白い腕章をしている﹂ ﹁私が話した人々のほとんどが、誰に投票するか決めていなかった﹂ ﹁待合室の誰もが小沢氏に対する少なくとも1つの不満を持っていた﹂ ﹁クラスの誰かが、私の出した全ての問題に答えられるはずだ﹂ ﹁多くの人々は賢明である
    SQL の相関サブクエリ (3) - 量化された比較述語 ALL, ANY
    hokorobi
    hokorobi 2010/11/06
    ALL, ANYは使ったことないな。
    リンク

  • 地獄のようによくわかるSQLテーブル結合 - こせきの技術日記


    テーブルの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で結合しません。 ※ おまけ。CROSSJOIN。 こんなの使いません。 ブクマ用画像。
    地獄のようによくわかるSQLテーブル結合 - こせきの技術日記
    hokorobi
    hokorobi 2010/09/23
    これで覚えられるかな。
    リンク

  • OracleのSQLのアンチパターンの問題集2

    CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

    OracleのSQLのアンチパターンの問題集2

  • INとEXISTSの違い - SQLer 生島勘富 のブログ


    INとEXISTSは違います。 BETWEENと、不等号の組合わせなど、等価になる記述法はあるのですけれど、INとEXISTSは基本的に同じ結果を返すことが可能ですが、意味は違います。 この違いが分かるにはインデックスを理解する必要がありますので、まずは、インデックスのイメージをつけてください。 まずはイメージ ここでも、まずはイメージで考えましょうね。 あなたは先輩の結婚式の司会を頼まれましたとします。イロイロと準備がありますが、余興で歌を歌う人がいるとき、予めカラオケの番号を調べておくでしょう。 食事の間のBGMについては、ラブソングの入ったiPodをつないでランダムで流すことにしましょう。しかし、新郎新婦にとって︵過去の恋愛経験上︶都合の悪い曲があり、チェックしてはじいておくことにしました︵なかなか、そつがない司会ですな︶。 これらの処理をSQLにするならば……。 ■カラオケの番号を
    INとEXISTSの違い - SQLer 生島勘富 のブログ
    hokorobi
    hokorobi 2010/07/04
    リンク

  • 情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方

    「安全なウェブサイトの作り方」は、IPAが届出(*1)を受けた脆弱性関連情報を基に、届出件数の多かった脆弱性や攻撃による影響度が大きい脆弱性を取り上げ、ウェブサイト開発者や運営者が適切なセキュリティを考慮したウェブサイトを作成するための資料です。 「安全なウェブサイトの作り方」改訂第7版の内容 第1章では、「ウェブアプリケーションのセキュリティ実装」として、SQLインジェクション 、OSコマンド・インジェクション やクロスサイト・スクリプティング 等11種類の脆弱性を取り上げ、それぞれの脆弱性で発生しうる脅威や特に注意が必要なウェブサイトの特徴等を解説し、脆弱性の原因そのものをなくす根本的な解決策、攻撃による影響の低減を期待できる対策を示しています。 第2章では、「ウェブサイトの安全性向上のための取り組み」として、ウェブサーバの運用に関する対策やウェブサイトにおけるパスワードの取扱いに関す

    情報処理推進機構：情報セキュリティ：脆弱性対策：安全なウェブサイトの作り方
  • 1 2 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.