SQLアンチパターン
本書はDB設計やSQL記述の際に避けるべき事柄を1章で1つ、25個紹介する書籍です。リレーショナルデータベースを中心に据えたシステム開発には、様々な場面で陥りやすい失敗（アンチパターン）があります。本書はデータベース論理設計、データベース物理設計、クエリの記述、アプリケーション開発という4つのカテゴリに分け、それぞれの分野におけるアンチパターンを紹介し、失敗を避けるためのより良い方法を紹介します。複数の値を持つ属性や再帰的なツリー構造の格納から、小数値の丸めやNULLの扱いに起因する問題、全文検索やSQLインジェクション、MVCアーキテクチャなど、実践的かつ幅広いトピックを網羅します。日本語版では、MySQLのエキスパートとして著名な奥野幹也氏によるアンチパターンを収録。データベースに関わるすべてのエンジニア必携の一冊です。 本書への称賛の声 監訳者まえがき はじめに I部 データベース論
SQLとJSONをNode.js上で組み合わせた新言語「ql.io」をeBayが公開
eBayが、JavaScriptアプリケーションからSQL文のような形式でデータベースへの問い合わせを記述できるDSL（ドメイン固有言語）のql.ioを発表。オープンソースとして公開しました。 現在、多くのWebアプリケーションが、バックエンドとのデータのやりとりにHTTPをベースにしたAPIを用いています。しかし、WebベースのAPIによってデータを取り出すのは、プログラマにとって実は手間のかかることです。 例えば、キーワードを入力すると関連する商品の名前、詳細、購入者の評価をユーザーに表示する、というWebアプリケーションでは、まずキーワードでデータベースを検索して商品IDを取得し、今度はその商品IDをキーにして名前や概要、評価の情報を取得する、といったように、APIを繰り返し呼び出す必要があります。 ql.ioはこうした内容をSQLのように分かりやすい記述で実現するだけでなく、複数の
「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH
グーグル、「Google Cloud SQL」を発表。Google App EngineにMySQLをベースにしたリレーショナルDBを追加
グーグルは同社のクラウドでリレーショナルデータベース機能を利用できるサービス「Google Cloud SQL」を公開しました。Google Labsの扱いで、限定プレビューとなっています。 グーグルはGoogle Cloud SQLを次のように紹介しています。 By offering the capabilities of a MySQL database, the service enables you to easily move your data, applications, and services into and out of the cloud. （略） To ensure that your critical applications and services are always running, Google Cloud SQL replicates data to
変数に型のない言語におけるSQLインジェクション対策に対する考察(5): 数値項目に対するSQLインジェクション対策のまとめ - 徳丸浩の日記(2007-09-24)
_数値項目に対するSQLインジェクション対策のまとめ 一連の議論では、以下の条件におけるSQLインジェクション対策について議論している。 SQLインジェクション対策において、バインド機構が利用できない(したくない) 変数に型のない言語(Perl、PHP、Rubyなど)を使用している 数値型の列の場合 この場合の対策としては、以下の二種類が機能する。 SQL文組み立ての前に、数値としての妥当性検証を行う 数値項目もシングルクォートで囲み(クォートし)、文字列リテラルと同様のエスケープを行う 数値項目もクォートする方法 このうち、後者の積極的な推進者として大垣靖男氏がおられる。例えば、以下のような記事 すべての変数をエスケープする対策 この方法はすべてのデータベースに利用できる対策です。文字列，整数などデータ型に関わらず変数すべてを文字列としてエスケープすることにより，SQLインジェクションを
数値項目に対するSQLインジェクション対策 - ockeghem's blog
文字列項目に対するSQLインジェクション対策は、「'」(シングルクォート)や「\」(円マーク、バックスラッシュ)のエスケープであるが、数値リテラルなどはエスケープでは対策できない。 ここで、なぜ文字列に対してエスケープ処理が対策になるかを復習しておこう。それは「どんな文字(列)に対しても正しいSQL文を生成する」ためである。一方、数値の場合は、どんな数値であってもエスケープ処理などは元々必要ない。それにも関わらずSQLインジェクション脆弱性が混入するのは、数値を想定した変数に数値以外の文字が混入するからに他ならない。 すなわち、文字列の場合と数値の場合は、対策の前提が異なるわけである。 ここで、高木浩光氏からの批判に戻ると、関連する内容は以下のとおりである。 「対策は入力値の妥当性検証」 < それは違う。SQL文構成時直前に型変換（ないし型検査）する。文字列のクオート同様 以下、いくつかの
SQLの数値リテラルをシングルクォートでくくる手法について - とある技術屋の戯言
結論 セキュリティ対策の一環としてSQLの数値リテラル(が期待されるパラメータ)をシングルクォートでくくる(文字列扱いする)手法は使用すべきでない 理由 少なくともMySQLでは標榜されている通りの動作はしない上、意図しない副作用が発生する。 解説 数値リテラルをシングルクオートでくくる手法は、これを推奨する大垣氏によると次のような効果があるとされています。参考:なぜPHPアプリにセキュリティホールが多いのか? 第14回 減らないSQLインジェクション脆弱性 攻撃目的の入力が行われてもSQLインジェクションが発生しない 簡単に攻撃用の文字列が検出できる これらはどちらも数値型が期待されるパラメータに不正なデータが渡されるとクエリエラーが発生することが前提となっています。例として、 SELECT * FROM table WHERE id = $VALUE; --ここでidは整数型 というS
地獄のようによくわかる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で結合しません。 ※ おまけ。CROSS JOIN。 こんなの使いません。 ブクマ用画像。
NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
データベース研究者の大御所、マイケル・ストーンブレイカー氏が開発し、NoSQLデータベースをも上回る性能を発揮するリレーショナルデータベース「VoltDB」。前回の記事では、その特徴と、NoSQLデータベースのCassandraとのベンチマーク比較を紹介しました。 今回はVoltDBのアーキテクチャについて調べたことをご紹介しようと思います。基本的にはVoltDBのWebサイトやリンク先の内容を基にしています。また、ブログ「独り言v6」のエントリ「VoltDB登場 – RDBMSのようでRDBMSではない新システム」も参考にさせていただきました。 シェアドナッシングな分散インメモリデータベース VoltDBのアーキテクチャは、FAQのページで以下のように説明されています（英語を訳したものを引用しています。以下同じです）。 VoltDBは、シェアドナッシングなサーバ群から構成されるスケーラブ
SQLiteのテストコードは4567万8000行！ 本体のコードは6万7000行
軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。本体のソースコードは約6万7200行（67.2KSLOC、Kilo Source Lines of Code：空行やコメントを除いた行数）なのに対し、テストコードはなんと4567万8300行（45678.3KSLOC）だと紹介されているのです！ これはテストコードが本体の約679倍もの大きさだということになります。 100％のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang
NoSQL登場の背景、CAP定理、データモデルの分類
その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLとORM(Object-Relational Mapping）では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ
group byはorder byより先に処理される。これ重要。 - Webtech Walker
今日はちょっとだけはまったSQLの話し。例えばブログのエントリーについたコメントが新しい順にエントリーをソートしたいときを考えてみます。 テーブル構成はこんな感じ。 CREATE TABLE `entry` ( `id` int(11) NOT NULL auto_increment, `title` text, `body` text, `created_at` datetime default NULL, PRIMARY KEY (`id`) ); CREATE TABLE `comment` ( `id` int(11) NOT NULL auto_increment, `entry_id` int, `body` text, `created_at` datetime default NULL, PRIMARY KEY (`id`) ); で、入ってるデータはこんなん。 mysql
［Web 2.0 Expo］「これからのWebを支えるデータベースは“NoSQL”」---米10genのMerriman CEO
「今後12カ月以内にWebインフラを新しく立ち上げるプロジェクトの大多数は，プライマリ・データストアとしてRDB以外のデータベースを選ぶだろう」。オープンソースのデータベース開発プロジェクト「MongoDB」を支援する米10genのCEOであるDwight Merriman氏（写真1）は，「Web 2.0 Expo New York 2009」でこう予測した。 Merriman氏は，「表と表の関係でデータを処理するリレーショナル・データベース（RDB）は，現在のWebアプリケーションの実態にそぐわない。リレーショナル・モデルに向かないデータ処理や分析処理が急増しつつある」と指摘。Webでは，写真や動画といった巨大データを多数のユーザーがやり取りし，クレジットカード情報もあればTwitterのつぶやきまでと価値の異なるデータと混在している。このため最近Web技術者の間で「NoSQL」と呼ばれ
SQLインジェクションとは何か？その正体とクラッキング対策。
世間では、今Gumblar祭りが勃発中であり、SQLインジェクションがニュースに出てくることは少なくなったが、だからと言ってSQLインジェクションの脅威がなくなったわけではない。SQLインジェクションはGumblarを仕掛ける手段としても利用されることがあり、Webアプリケーションを提供する全ての人にとって、対策を講じなければいけない驚異であることに変わりはない。SQLインジェクションという攻撃手法が認識され、大いに悪用されているにも係わらず、その本質に迫って解説している記事は少ないように思う。従来のWeb屋だけでなく、今やアプリケーション開発の主戦場はWebであると言っても過言ではなく、そういう意味ではSQLインジェクションについて理解することは、全てのプログラマにとっての嗜みであると言えるだろう。 というわけで、今日は改めてSQLインジェクションについて語ってみようと思う。 SQLイン
SQLをより賢く使うための12のヒント - builder by ZDNet Japan
あなたのユーザーはSQLについてまったく知らないかも知れないが、その価値についてはしっている可能性が高い。SQLはあらゆる場所で使われており、学ぶのも簡単で、SQLを使ったソリューションは実装も簡単だ。SQLをあまり使わないにしろ、よく使うにしろ、SQLを賢く使えば、エラーを避け、性能を向上させることができる。 多くのSQLは各ベンダー独自の仕様を持っている。以下で紹介するヒントはJetとTransact-SQLで使えるものだが、ほとんどのSQL製品はこれに似ている。 1: AccessのSQLウィンドウでJet SQLを利用する Accessユーザーは、クエリを作成するたびにSQLステートメントを作成している。ただ、彼らがそれを知らないだけだ。彼らが使っているクエリデザインウィンドウは、実際にはSQLを視覚的に表現したものだ。ほとんどのユーザーは、自分が必要とする適切なSQLステートメン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Hook - Source Of All Unlikely Stories
IDEA * IDEA
個別「20100916033730」の写真、画像 - koseki2's fotolife
ブログ – H2O space