タグ

2011年12月12日のブックマーク (5件)

  • PHPから見たPostgreSQLの数値データ型(数値リテラル) | Let's POSTGRES

    smallintはint2、integerはint4 およびint、bigintはint8と同意です。またsequenceを使うという機能を除けば、serialはintegerと、bigserialはbigintと同様の動きをします。これらは小数点以下のない「整数値」です。 serial、bigserialの値のフォーマット・範囲のチェックなどはinteger、bigintと同じですので、以下はそれぞれに読み替えてください。 64bitシステムでの整数値のチェック smallintとinteger まず、値が負でない(すなわちマイナス記号がつかない)ことを必須にしてしまってよければ、smallintやintegerのチェックは簡単です。 if(!ctype_digit($_REQUEST['num']) || $_REQUEST['num'] > 32767) { // NG処理 } これ

  • PostgreSQL 9.0から使える識別子とリテラルのエスケープ

    (Last Updated On: 2018年8月13日)PostgreSQL Advent Calender用のエントリです。 エスケープ処理が必要なのにエスケープ用のAPIが無い状態は良くありません。エスケープしないために動かないのはまだ良い方です。エスケープが必要なのにエ スケープをしなくても動いてしまい、セキュリティ上の問題となる場合もあります。全てのアプリケーション・ライブラリはエスケープが必要なデータに対するAPIを持っておくべき です。今回はPostgreSQL 9.0から追加されたエスケープ関数を紹介します。 PostgreSQL使い始めて最初の頃に気づくのはuserなどの予約語がフィールド名に使えない事かも知れません。例えば、 yohgaki@[local] test=# CREATE TABLE user (name text); ERROR:  syntax erro

    PostgreSQL 9.0から使える識別子とリテラルのエスケープ
  • "BigData"では何が問題なのか? - 急がば回れ、選ぶなら近道

    ”ビッグデータで奇跡が起こる” はいどうも。まず、個人的には楽天的な進歩史観には、まったく組しない。 従って、突然に新技術ができて、なんか凄い事になる、というのはさらにまったく同意しない。すべからくブレイクスルーは課題解決により起こると思っているので、問題意識のないところに、こんなものできました的な発想は、基的にプラスにならないことが多いと思っている。現状のビッグデータブームは2011年の秋口現在は完全にハイプになっており、バブルと言ってもいいと思う。印象として、十数年前のナノテク・ブームに似ている。 とはいえ、過度の期待という側面を除けば、それなり効果もある部分もあり、”そこだけ”を見ていけばそれなりに効果はある(と思う)。大体において、今後は以下の二つのユースケース・カテゴリーに集約されると思う。すなわち、ビッグデータの拠り所はまずもって以下の2点だ。 1 Webのログ解析 というか

    "BigData"では何が問題なのか? - 急がば回れ、選ぶなら近道
    umitanuki
    umitanuki 2011/12/12
    うーん この人どこまで知ってるのだろう。
  • marisa-trie における rank/select の実装 - やた@はてな日記

    概要 rank/select は簡潔データ構造(Succinct Data Structures)の核になる関数です.ビット列の k ビット目までに含まれる 0, 1 の数を求めるのが rank,k 番目の 0, 1 の位置(Index)を求めるのが select であり,ビット列の密度(1 の割合)によって,いろいろな実装があります. marisa-trie では,0, 1 の割合が極端に偏らないビット列を想定するとともに,32-bit 環境における性能の劣化を防ぐために,64-bit 整数を使わないようにしました.そのため,ほとんどの部分は以前に開発したライブラリからの流用ですが,新しく書き直した部分もあります.ちなみに,索引のサイズはビット列の長さ n bits に対して (1/4)n bits です. 基 ビット列の実装 ビット列の格納には 32-bit 整数の配列を使っています

    marisa-trie における rank/select の実装 - やた@はてな日記
  • C++: 編集距離を求めるアルゴリズム

    編集距離(edit distance)とは二つの文字列がどの程度異なっているかを示す数値であり、レーベンシュタイン距離(Levenshtein distance)を指すことが多い。文字の挿入、削除、置換それぞれを一つの操作として必要な操作の最小数を求めるものだ。例えば、kittenとsittingの編集距離を求める場合、下記のように3回の操作でkittenをsittingに変更できるので編集距離は3となる。 1. sitten (k を s に置換) 2. sittin (e を i に置換) 3. sitting (g を挿入) そこで今回は編集距離を求める複数のアルゴリズムについてC++で実装してみた。 動的計画法 編集距離を求めるもっとも一般的なアルゴリズムは、動的計画法(dynamic programming)だろう。計算時間はO(mn)であり、手軽だ。C++で書いたコードを下に示