タグ

sqlに関するperezvonのブックマーク (13)

  • GitHub - layerware/hugsql: A Clojure library for embracing SQL

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - layerware/hugsql: A Clojure library for embracing SQL
    perezvon
    perezvon 2017/12/30
    “A Clojure library for embracing SQL.”
  • そろそろ履歴データについて真面目に考えてみていいんじゃないの - iakioの日記

    WEB+DB PRESS Vol.75の「理論で学ぶSQL再入門/履歴データとの上手なつきあい方」が面白かったと感想を書こうと思っていたらもうVol.76が出そうなのでいい加減慌てて書きます。 さてこの記事では、リレーショナルモデルが苦手とするデータ構造の1つとして履歴データを挙げています。 もしかすると「履歴データ」であるということを気づかずにデータベースの設計、クエリの記述をしたことがあるかもしれません。 この記事ではショッピングサイトの価格表を例としています。 価格表が常に現在の価格のみを扱うのであれば問題ありませんが、ある期間に価格を変えたことも価格表に含めるのであればそれは「履歴データ」となります。記事から一部引用するとこんな感じ item price start_date end_date 懸垂マシーン 18000 2010-01-01 2011-12-31 懸垂マシーン 20

    そろそろ履歴データについて真面目に考えてみていいんじゃないの - iakioの日記
    perezvon
    perezvon 2013/08/28
  • 削除フラグのはなし

    6. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 8. id name pass is_deleted 1 ryu xxx FALSE 2 ken xxx FALSE 3 honda xxx TRUE 3 honda xxx FALSE

    削除フラグのはなし
    perezvon
    perezvon 2011/08/14
    primary_key < 0 ならば削除とみなすというテクニック
  • Home Assistant

    perezvon
    perezvon 2009/07/17
    sqlamp is an implementation of an efficient algorithm for working with hierarchical data structures
  • なぜMySQLのサブクエリは遅いのか。

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

    なぜMySQLのサブクエリは遅いのか。
  • 帰ってきたHAVING句:CodeZine

    はじめに SQLのクラスを教えるとき、最大の課題の一つが、生徒たちがそれまでに手続き型言語から身に付けたことを、一度「頭から追い出す(unlearn)」ことだ。私がそのとき採る一つの方法は、処理を「レコード単位」ではなく、集合という観点から考えるよう強調することである。 ――――J.セルコ  SQLの考え方を習得するときに最大の障壁となるのが、私たちの多くが慣れ親しんだ手続き型言語の考え方(ソート、ループ、分岐、代入、等々)です。SQL質を理解するには、私たちの心に強固に貼り付いてしまった思考パターンを、一度ベリベリと引き剥がし、更地に戻してやる必要があります。それが、セルコが「unlearn」という言葉に込めたニュアンスです。セルコ自身、Fortranからプログラマとしてのキャリアを開始し、C、Algol、Pascalと手続き型言語を渡り歩いた後にSQLを身に付けた人物だけに、言葉に

    perezvon
    perezvon 2007/07/15
  • インジェクション系攻撃への防御の鉄則

    前回までは,主にクロスサイト・スクリプティングのぜい弱性とその対策について解説してきた。最終回となる今回は,クロスサイト・スクリプティング以外の「インジェクション系」ぜい弱性について解説する。具体的には,SQLインジェクション,OSコマンド・インジェクション,HTTPヘッダー・インジェクション,そしてメールの第三者中継である。 SQLインジェクション対策にはバインド変数の利用が最適 まず,SQLインジェクションから見ていこう。対策には二つの方法がある。一つは,SQLの「バインド変数(注1)」を使う方法である。バインド変数の書式はプログラミング言語によって異なるが,一例として,Perlを使った場合に,パスワード認証のSQLをバインド変数で書き換えた例を示す(図1)。 (注1) 「準備された文(Prepared Statement)」というのがJIS SQLでの用語だがあまり普及していない。バ

    インジェクション系攻撃への防御の鉄則
  • http://media.seasar.org/staging/hazimete_s2/chapter5.html

  • pointy-stick.com

    This domain may be for sale!

  • PreparedStatementを使用したSQLInjection対策 - masaのメモ置き場

    エスケープだけしてれば、セキュリティ対策が万全になる訳ではないですよ - masaのメモ置き場 の話について、高木さんより「PreparedStatementを使いなさい、動的パラメータの例は分岐で処理しなさい」、という趣旨のコメントを頂いてしまった。まだ、もやもや感があるので、もう少し考えてみる。 数値型チェックの話 select password from usertable where id = 入力値 (idが数値型) 入力値に 1 or 1 = 1 が与えられると・・数値型の列に数値型以外の値が渡された時に発生する問題は、どの層ならば対策可能で、どの層が責任を持つべきなの?という話。型の概念を持つ言語なら、データベース層に数値型の引数を受け付けるインタフェースが用意されていて、アプリケーション層ではそのインタフェースを呼び出すことになる。型変換はアプリケーション層が行うことになる

    PreparedStatementを使用したSQLInjection対策 - masaのメモ置き場
    perezvon
    perezvon 2006/12/04
  • 高木浩光@自宅の日記 - 駄目な技術文書の見分け方 その1

    ■ 駄目な技術文書の見分け方 その1 はてなブックマークのホッテントリを見ていたところ、300を超えるユーザに登録された以下の記事があった。 今夜分かるSQLインジェクション対策, 上野宣, @IT, 2006年11月2日 また上野宣か。顔見知りなのでズバリいくことにする。 しかし、その対策はまだ当に理解されていないように思える。 へえ。 終わりの方を見てみると、 Webアプリケーションの対策 入力値のSQLの特殊文字を適切にエスケープ 入力値=プログラム(プロセス)に外部から入ってくるもの シフトJISの場合には1バイト文字を整理 SQLの記述をなくすためにO/R(Object/Relational)マッピングを活用 攻撃者に役立つ情報を与えないために、不要なエラーメッセージ(データベースが出力するエラーなど)の表示を抑止 対策に「準備された文」(prepared statement)

  • カレーなる辛口Javaな転職日記 - それはJavaの問題ではないのでは

    http://q.hatena.ne.jp/1162199668 ビジネスロジックをどこに持ってくるか悩んでいます。 ストアドプロシージャにビジネスロジックを実装した方がパフォーマンスもよくなると思うのですが、社内的には反対意見も多いです。 普通に考えれば,特に理由がない限りは,ビジネスロジックは原則としてJavaの側に作るもんだと思うがな.ただ,あとの部分を見る限りは,理屈も分からないままに定説を鵜呑みにしているだけのように見える. 続きを読む http://d.hatena.ne.jp/JavaBlack/20061031#c1162344252 多分、SQLが出来る人は、Javaも出来ます。 Javaが良いという人は、基的にSQLは出来ません。 まず間違いなくウソです. 続きを読む Martin Fowler氏のサンプルのように、SQLJOINまでというものはオブジェクト指向とし

    カレーなる辛口Javaな転職日記 - それはJavaの問題ではないのでは
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。

  • 1