はじめに 木構造と呼ばれるデータ構造の一種があります。1つのルート(根)と呼ばれるノードを始点として、(通常)複数のリーフ(葉)と呼ばれるノードまでを経路で結んでできるデータ構造です。その名のとおり自然界にある「木」の構造ですし、学校時代、確率の授業で樹状図を書いた経験のある人もいるでしょう。 この構造は、私たちの周囲にとてもたくさん存在します。家系図や組織図も木ですし、IT関連の例では、ヒープやRDBのインデックス、ディレクトリ(フォルダ)によるファイルシステムやXMLも木構造です。Webの掲示板でも、最初の書き込みをルートとしてそれに対してコメントがつけられ、そのコメントにまたコメントがつけられるというプロセスで木構造を形成します。ここでは1つの書き込みがノードになります。 このように、IT技術と木構造は切っても切れない関係にありますし、多くの分野で応用されてもいるのですが、実は長い
Core開発部のTです。 再帰的な関連を持ったデータをリレーショナルデータベースで扱う機会があったので紹介したいと思います。 そもそもMySQLをはじめとしたリレーショナルデータベースは、列と行で構成されるテーブルの構造体であり、木構造のような再帰的構造を表現することが苦手とされています。 ただ現在では、リレーショナルデータベースで階層構造を扱うにあたり、いくつかの解法が存在します。 隣接リストモデル 入れ子集合モデル 経路列挙型モデル 今回私は、経路列挙モデルを取り上げることにします。 経路列挙モデル 経路列挙モデルとは、対象ノードの先祖までの経路を属性として格納することで、木構造を表現するモデルです。 下記のディレクトリ構造を例に見ていきます。 経路列挙モデルでは、上記の構造を下記のように表現することができます。 directory path top /top/ marketing /
はじめに SQLアンチパターンという本を読んでいたら、再帰的なデータに対して『閉包テーブル(Closure Table)』という考え方があっったので、MySQL 5.6 で試してみました。 再帰的なデータとは、例えば上司を1人までもつことができ、部下は複数持つことができる、下記の組織図のようなツリー構造のデータのことを指します。 テーブル作成 それでは早速テーブルを作成してみましょう。 CREATE TABLE `Employees` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `name` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE `TreePaths` ( `ancestor` bigint(20) N
第二章 ナイーブツリー 「ブログのコメント欄をスレッド形式で見れるようにしたいよね・・・」 目的 階層構造を格納して、クエリを実行する こんなテーブル設計したとして、 comment_id parent_id comment etc
6. 脆弱性のあるアプリケーション Copyright © 2010-2014 HASH Consulting Corp. 6 @books = Book.where( "publish = '#{params[:publish]}' AND price >= #{params[:price]}") 山田 祥寛 (著) Ruby on Rails 4 アプリケーションプログラミング 技術評論社 (2014/4/11) に脆弱性を加えましたw ※元本に脆弱性があるわけではありません 7. UNION SELECTにより個人情報を窃取 Copyright © 2010-2014 HASH Consulting Corp. 7 priceに以下を入れる 1) UNION SELECT id,userid,passwd,null,mail,null,false,created_at,updated
SQLはデータベースからデータを抽出したりするための言語です。 この文書は、ErogameScapeのデータベースからSELECTを使って自由自在にデータを取得できるようになることを目標にします。 エロゲーをやりはじめる大学生くらいのときに、大学の講義でデータベースを学んで、退屈だなーと思った時に、ErogameScapeでSQLを学ぶことで、少しでもSQLに興味を持って、自身でデータを加工することを学習して頂けると幸いです。 ※私の大学のリレーショナルデータベースの授業では、自分の身の回りの何かをER図に落とし込んで、DBを設計し、PostgreSQLに実装し、実際にデータを入力してSELECTしてみるところまでをやりました。 ER図という概念を学んだとき「ああ、これは面白い」と思いました。 先生はこう言ったのです。 「ER図に落とし込むと、思いもよらなかったことが分かる。」と。 当時、
オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基本だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか | [ bROOM.LOG ! ] エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog SQLへの安全な値の埋め込み方について、ここ数日で色々議論というか意見の投げ合いがありましたが、自分としての考えをまとめておきます。 1. SQLに値を埋め込む場合は、プリペ
社内で、SQLインジェクションについてあらためて原理・原則から議論したいねという風潮がにわかに起こったので、ひとまずは叩き台として僕の方でまとめて皆で議論しましょうというわけで、以下のような資料を作成した。 社内勉強会用の資料なのだけど、僕は別にセキュリティに詳しいわけでもないし、ましてやPHPのことは素人なので、外部の識者にレビューしていただいて、できるだけ正しい知識に基づいて議論できればと思い、まずスライドを先行公開することにした。そうしたところ、Twitter上で多数の識者よりいろいろとご指摘いただいて、少くとも決定的におかしな内容にはなっていないものになったようだ。ありがとうございます。 僕らの職務のひとつに「セキュリティ関連」というものも謳われているので、そのあたりの知識普及・基盤整備についても、仕事のひとつとして行っている。先にも書いた通り、僕自身がその点についてよく理解できて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く