[B! SQL] takutakumaのブックマーク

[SQL] Window関数を使ってデシル分析〜ntile関数で優良顧客を抽出する〜 | DevelopersIO

はじめにまずはじめにデシル分析とは全顧客の購入金額を高い順に１０等分にして各ランク(デシル)の購入比率や売り上げ構成比を算出して優良顧客を探ろうとする分析だそうです。マーケティングの世界では「80:20の法則」や「2:8の法則」と呼ばれるパレートの法則というものがあるそうです。 Wikipediaによると商品の売上の8割は、全商品銘柄のうちの2割で生み出している。売上の8割は、全従業員のうちの2割で生み出している。仕事の成果の8割は、費やした時間全体のうちの2割の時間で生み出している。所得税の8割は、課税対象者の2割が担っている。プログラムの処理にかかる時間の80%はコード全体の20%の部分が占める。 Wikipedia デシル分析で上位２０％の顧客を抽出できればマーケティングに活かせそうですね。環境 PostgreSQL 9.5.4 実現したいこと直近４カ月で利用した

takutakuma 2016/08/29

SQL

リンク

SQLアンチパターン幻の第26章「とりあえず削除フラグ」

SQLアンチパターン 26章「とりあえず削除フラグ」 2015/08/31 @ GMO Yours #ronsakucasual https://atnd.org/events/68902Read less

takutakuma 2015/09/01

SQL
DB

リンク

The annotated table of contents

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

takutakuma 2014/10/20

まとまってそうなので、後で読む

リンク

とある診断員とSQLインジェクション

PostgreSQLの行レベルセキュリティと SpringAOPでマルチテナントのユーザー間情報漏洩を防止する (JJUG CCC 2021 Spring)Koichiro Matsuoka

takutakuma 2014/05/26

リンク

エロゲーマーのためのSQL -エロゲーマーのためのSQL-

SQLはデータベースからデータを抽出したりするための言語です。この文書は、ErogameScapeのデータベースからSELECTを使って自由自在にデータを取得できるようになることを目標にします。エロゲーをやりはじめる大学生くらいのときに、大学の講義でデータベースを学んで、退屈だなーと思った時に、ErogameScapeでSQLを学ぶことで、少しでもSQLに興味を持って、自身でデータを加工することを学習して頂けると幸いです。 ※私の大学のリレーショナルデータベースの授業では、自分の身の回りの何かをER図に落とし込んで、DBを設計し、PostgreSQLに実装し、実際にデータを入力してSELECTしてみるところまでをやりました。 ER図という概念を学んだとき「ああ、これは面白い」と思いました。先生はこう言ったのです。「ER図に落とし込むと、思いもよらなかったことが分かる。」と。当時、

takutakuma 2014/01/02

SQL

リンク

間違いだらけのSQL識別子エスケープ

これから3回連載の予定で、SQL識別子のエスケープの問題について記事を書きます。SQL識別子のエスケープについてはあまり解説記事などがなく、エンジニア間で十分な合意がないような気がしますので、これらの記事が議論のきっかけになれば幸いです。 3回の予定は以下のとおりです。間違いだらけのSQL識別子エスケープ(本稿) SQL識別子エスケープのバグの事例 SQL識別子は結局どうすればよいかということで、まずはSQL識別子のエスケープの失敗例について説明します。この失敗例はあくまで説明のために作ったもので、実際のものではありません。また、想定が「ありえない」と思われるかもしれませんが、意図的なものですのでご容赦いただければと思います。また、「間違いだらけの」というタイトルは、今回の題材が間違いだらけという意味であり、巷のSQL呼び出しがそうであるという意味ではありません。本稿に登場する人物と団

takutakuma 2013/12/25

リンク

SQLインジェクション対策に正解はない

最近、SQLインジェクションのネタが盛り上がってるようだ。下記のTogetterまとめあたりが震源地だろうか。「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめまとめを読んだ感想としては、「どちらの意見も間違ってはいない」というものだ。前提あるいは見方が異なるために、見解の相違が生じているだけのように思う。SQLインジェクションについては私も若干思うところがあるので意見を書いておこうと思う。攻撃を防ぐのは難しいSQLインジェクションをはじめとするセキュリティ対策が難しいのは、ひとつでも穴があると致命的なダメージを受け得るということだ。「どうやって効率よくコードを書くか」とか「コードのメンテナンス性を高めるにはどう書くべきか」みたいな議論とは全く質が異なる議論が必要になっ

takutakuma 2013/12/14

SQL

リンク

SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?

コードゴルフという競技があります。与えられた問題（例えばFizzBuzz）を解くコードを、いかに短いプログラムで実現できるかというものです。脆弱性の世界でもXSS Golfというものは既にあるようで、我らがはせがわようすけ氏にも、「短いXSSの話」というプレゼン資料が公開されています。第2回のOWASP Japanローカルチャプターミーティングでの講演ですね。これ、面白いので、まだ見ていない方はぜひご覧になって下さい。 XSSがあるならSQLインジェクションはどうかということで、ちょっと考えてみました。この手の遊びは、問題のルールが命というというところはありますが、最初なのであまり厳密に考えずにだらだらとやってみます。攻撃対象プログラムやはり、SQLインジェクション攻撃でみなさまおなじみの認証回避がよいのではないかと思いました。拙著「体系的に学ぶ安全なWebアプリケーションの作り