IPAの「安全なSQLの呼び出し方」が安全になっていた
(Last Updated On: 2018年8月4日)IPAは「安全なSQLの呼び出し方」（PDF）を以下のURLから公開しています。 http://www.ipa.go.jp/security/vuln/websecurity.html 「安全なSQLの呼び出し方」は危険である、とするエントリを書こうかと思い、内容を確認するとそうでもありませんでした。 訂正：ツイッターで徳丸氏に確認したところ、徳丸氏もエスケープを含めたSQLインジェクション対策が必要であると考えられていた、ことを確認しました。徳丸氏にはセキュリティ専門家として大変不名誉な記述であった事を訂正し、深くお詫びいたします。内容についての修正は、識別子エスケープについてブログに書くとの事でしたのでブログの内容を確認してから修正します。 別冊の「安全なSQLの呼び出し方」は基本中の基本である「正確なテキストの組み立て」によるセ
SQLのエスケープ
(Last Updated On: 2018年8月4日)SQLにエスケープなんて必要ないと考えている方も居るとは思いますが、現実にはエスケープを知っておくことは必須と言っても構わないと思います。 既にSQL識別子のエスケープについては書きましたが、今回はSQLエスケープというよりは安全にSQLデータベース利用する話です。先ずはエスケープの話を全て終わらせよう、と思っているのですがSQLエスケープのエントリが無いので作りました。私のブログを読んでいる方はエスケープ処理、プリペアードクエリの利用方法などはよくご存知だと思うのでここの部分は省略しています。 現在広く利用されているSQLデータベースのほとんどがプリペアードクエリをサポートしています。プリペアードクエリを利用すれば、SQL文とパラメーターを分離できるため、パラメーターがSQL文の一部として解釈されてしまう問題を回避できます。 プリペ
qpstudyで発表したスライドをアップロードしました。
本日、qpstudyで「データベースとは」という内容について、そして「リレーショナルモデルとは」という内容について話す機会を頂いた。リレーショナルモデルという硬い内容であったにも関わらず、出席者の皆さんには最後まで良い反応をして頂けたように思う。実はリレーショナルモデルについて誤解している、あるいは知らない人が本当に多い、そして良い解説書がないということを普段問題として感じており、そういった背景から今回qpstudyの話を引き受けさせて貰った。今回発表した内容が皆さんのお役に立てば幸いである。 発表の内容はほぼ現在WEB+DB PRESSで連載している「理論で学ぶSQL再入門」のいくつかの回のものを要約したものになっている。連載ではさらに詳しい内容について説明しているので、興味のある人はぜひWEB+DB PRESSのバックナンバー（連載はVol.68〜）を購入して頂きたい。 本日発表したス
RDBMSに関する典型的な誤解が絶えないという現実
新入社員必読、データベースの基本を理解しよう - データベースはなぜ必要なの？：ITproという記事に対するブクマで次のようなIDコールが来た。（現在はコメント返しへのお礼が入っているので、文字数制限のためオリジナルのコメントは少し切り詰められている。） "リレーショナルデータベースはすべてのデータを2次元の表形式で表現"こういうのもリレーションが2次元構造という誤解の一種なんだろうか。id:nippondanjiさんが書いてたような。 さて、この疑問に対する正解は如何なるものだろうか？ つい先日「7つのデータベース 7つの世界」の書評で書いたばかりだが・・・ 言うまでもなくその通りである。 リレーションが2次元的な構造を持っているというのは典型的な誤解だ。（ちなみにリレーションの次元は属性の数に等しい。n個の属性があるリレーションはn次元。）リレーショナルモデルについてちゃんと学習してい
SQLアンチパターン - 開発者を待ち受ける25の落とし穴 (拡大版)
unassert - encourage reliable programming by writing assertions in productionTakuto Wada
LifeGameをSQLで - ShiroKappa Blog
先日(12/03)にcoderetreatというイベントに参加してきた。参加の感想は別途ブログに書くかもしれないとして、お題となったライフゲームは、参加して初めて知った。 6人の方とペアプロでこのお題に取り組んだが、すべてPHPで書いた。次回参戦する機会があれば別の言語でチャレンジしてみたい。 このお題を3回くらいペアプロした後で、ゲームのロジック（死活判定）をSQLでできないかなと思ったので書いてみた。 コードの汚さやSQLの美しくなさはご容赦いただきたいが、隣接するマスを表現するのにSpatial Informationを使えないかなと思って書いてみた。 ⇒コードはこちら ※ちなみに20x20位のマップで激遅になるので10x5位で動かしてみてほしい。 MySQLにはOpenGIS準拠のSpatial Informationの実装があるが、一部インプリメントされていないfunctionも
KateでスマートにSQLを編集しよう！
このところ、KDEの進化が著しい。先月の終わり頃にKDE 4.6がリリースされたのだが、前回のバージョン4.5は去年の8月だったので、5ヶ月ちょっとでのバージョンアップとなる。KDEは4.5でかなり品質が向上したように思うのだが、4.6では心踊る新機能が目白押しだ。その中で、特に筆者の目を引いた新機能がひとつある。それは、KateSQL（Kate用SQLクライアントプラグイン）だ。 Kateとは？ひとことで言うとかなりイケてるエディタである。Qtを使って書かれており、KDEに標準的に含まれている。EmacsやVimのように、ゴリゴリにカスタマイズしまくって使うことを前提にした本格的なエディタとは少し毛色は異なるが、種々のプログラム言語やマークアップ言語をサポート（シンタックスハイライトやオートインデントなど）していたり、Zen-Codingに似た入力モードを搭載するなど、かなり気の利いたエ
10 things in MySQL (that won't work as expected).
(I just discovered cracked.com) #10. Searching for a NULL SELECT * FROM a WHERE a.column = NULL In SQL, a NULL is never equal to anything, even another NULL. This query won't return anything and in fact will be thrown out by the optimizer when building the plan. When searching for NULL values, use this instead: SELECT * FROM a WHERE a.column IS NULL #9. LEFT JOIN with additional conditions SELECT
NoSQLの成功は1:10問題にかかっている | gihyo.jp
江島健太郎氏によるブログ記事です。昨今におけるNoSQLの人気急上昇ぶりと、対するRDBMSの評価が下がっていることについて冷静に考察しています。 OracleやMySQLなどRDBMSはすでに成熟した段階にある一方、柔軟性やスケール性において弱点を抱えています。その点、NoSQLはRDBMSが抱えている問題を解消しているだけでなく永続性もある程度サポートしていることから持てはやされ、「SQLデータベースは死んだ」という極論まで出るようになってしまいました。そしてMongoDBのように「書き込み時にはディスクに同期しない」という、永続性においてはある意味致命的な問題をトレードオフとして認識せず、ただ賞賛する界隈に対して、皮肉の意味を込めた動画やサービスが作られ話題となりました。 江島氏は「NoSQLはSQLを極めてこそ真価を発揮する」と主張しています。そして原点に立ちかえり、そもそもWe
MySQL複合INDEXの威力
予想以上の効果がでたので記事に残します。 DBの情報を元に統計を行うSQLとプログラムの性能改善で、複合INDEXを試してみました。 MySQLは、4.2です。 対象となったSQLは複数ありますが、そのうちほとんどは４つのテーブルをJOINしています。取得条件を変えながら情報を取得し、最後に目的別に合算するっていうことをやっています。４つのテーブルのうち３つはデータ数200万オーバー、１つは100万オーバー。 最初は、こんな状態 +----+-------------+-------+--------+----------------------------------------------+ | id | select_type | table | type | Extra | +----+-------------+-------+--------+-----------------
NoSQLの成功は1:10問題にかかっている:Kenn's Clairvoyance
ここ2-3年ほど、いわゆる非SQL系データベースがホットな話題になってきています。このムーブメントを総称して「NoSQL (Not-only SQL)」と呼ばれることが多いようです。まるでSQLを否定しているかのような誤解を招きやすい用語ですが、かといってキー・バリュー型データストアや列指向DBを総称できる他の呼び方もないので、このエントリではNoSQLという用語を使うことにします。 OracleやMySQLなどのSQLデータベースが成熟していく一方で、SQLデータベースを特徴づける弱点である柔軟性のなさ、堅牢さと引き換えに犠牲になった更新性能の低さ、スケールアウトの難しさなどから、「何でもかんでもRDB」から「目的に応じた永続化」が模索される流れになってきました。 時を同じくして、キャッシュサーバの世界でも、MemcachedのもつシンプルなAPIの使いやすさが評価される一方、LRUによ
VoltDB Decapitates Six SQL Urban Myths and Delivers Internet Scale OLTP in the Process - High Scalability -
What do you get when you take a SQL database and start a new implementation from scratch, taking advantage of the latest research and modern hardware? Mike Stonebraker, the sword wielding Johnny Appleseed of the database world, hopes you get something like his new database, VoltDB: a pure SQL, pure ACID, pure OLTP, shared nothing, sharded, scalable, lockless, open source, in-memory DBMS, purpose-b
MySQL のNULL ではまったことあれこれ - LukeSilvia’s diary
MySQL に限らず、SQL のNULL の仕様には何回か「えっ」と驚くことがあったのでメモしておこうと思います。5.1 版の日本語マニュアルがなかったものについては、4.1 のマニュアルを参照しました。 そもそもNULL は何を意味するか NULL は未定義または、不明を意味する。「電話番号を持たない」ということを表現する場合は、NULL ではなく、空の文字列を使う。 NULL 値というものを SQL 初心者はよく混乱します。SQL 初心者は、多くの場合、NULL が空文字 "" と同じであると考えてしまいます。これは違います。たとえば、以下のステートメントは完全に別のものです。 mysql> INSERT INTO my_table (phone) VALUES (NULL); mysql> INSERT INTO my_table (phone) VALUES (""); どちらのス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SQLアンチパターン - 開発者を待ち受ける25の落とし穴
MySQL事始 SQL文(1) SELECT