タグ

SQLに関するmasa1001のブックマーク (7)

  • 今からでも遅くない JPAを学ぼう!(前編) O/Rマッピングフレームワークへの招待

    JPAとは JPA(Java Persistence API)とはオブジェクトの世界からリレーショナルの世界へ、あるいはその逆への変換を行うためのAPIです。 それでは何もJPAを使わずともHibernateやiBatisを既に使っているから必要ないのではと考えられた方も多いかと思います。確かに既にそれらのO/Rマッピングフレームワーク(以降、O/Rマッパー)を利用されているのであれば特に必要ないのかもしれません。 そう思った方も少し待ってください。データベース製品の多様性を隠ぺいするためにJDBCが考えられたように、あるいはMOM製品の多様性を隠ぺいするためにJMSというAPIが考えられました。ところがO/Rマッパーの違いを隠ぺいするためのAPIは存在しなかったのです。iBatisを使用されている方にはあまり嬉しくないかもしれませんが、JPAの仕様作成の中心人物こそHibernateプロ

    今からでも遅くない JPAを学ぼう!(前編) O/Rマッピングフレームワークへの招待
  • Google App EngineがSQLデータベースをサポートへ。エンタープライズ向けサービスを拡充

    Google App EngineがSQLデータベースをサポートへ。エンタープライズ向けサービスを拡充 グーグルは5月19日(現地時間)に米サンフランシスコで開催されたイベント「Google I/O」の基調講演で、エンタープライズ向けにフォーカスした「Google App Engine for Business」を発表しました。その内容を紹介しましょう(基調講演の内容は、記事「[速報]Google I/Oで発表された4つのポイント:VP8オープンソース化/Chrome Web Store/VMwareとの協業/Google App Engine for Business」をご覧ください)。 基調講演で最後の発表者として壇上に立ったのは、グーグルのKevin Gibbs氏。App Engineがエンタープライズに受け入れられるようにするためには、いくつかのバリアを乗り越えなければならないと語

    Google App EngineがSQLデータベースをサポートへ。エンタープライズ向けサービスを拡充
  • 実録・4大データベースへの直接攻撃

    情報の入れ物、データベースは大丈夫ですか 皆さんこんにちは、川口です。そろそろGumblarの話に飽きてきたところでしょうか。今回は以下の4種類のデータベースで、管理用ポートをインターネットにオープンしているとどうなるかについて調べた結果を取り上げます。いずれも管理用ユーザーのパスワードは「脆弱なもの」に設定されています。 Oracle(1521/tcp) SQL Server(1433/tcp) MySQL(3306/tcp) PostgreSQL(5432/tcp) 右側に書いてある番号が管理用ポート番号です。データベースを管理する場合、これらのポートをインターネットに対してオープンにする必要はないはずです。しかし、これらのポートに対して外部から“直接”接続するインシデントが年に数回は発生しています。 このようなインシデントは、大学のネットワークに接続したサーバがほとんどですが、ホステ

    実録・4大データベースへの直接攻撃
    masa1001
    masa1001 2010/05/19
  • IPA、PDF資料「安全なSQLの呼び出し方」を公開 SQLインジェクション攻撃への具体的な対策書

    IPA(独立行政法人情報処理推進機構)は18日、Webアプリケーションの安全な実装方法を解説した資料「安全なSQLの呼び出し方」(PDF)を公開した。全5章(計40ページ)および付録からなり、冊子「安全なウェブサイトの作り方」(PDF)の別冊として、公式サイトより入手できる。 「安全なSQLの呼び出し方」では、SQLインジェクション攻撃にどのような対策を取れば安全であるかの要件を検討し、安全なSQL呼び出しを実現する考え方を製品によって整理しながら、具体的なケースの調査結果を示している。 特に第5章では、5種類のプログラミング言語とデータベースの組み合わせ(JavaOraclePHPとPostgreSQLPerlJavaMySQLASP.NETSQL Server)における安全な実装方法とソースコードの書き方を解説しているほか、付録には、文字コードに関する問題など特定のデータ

    IPA、PDF資料「安全なSQLの呼び出し方」を公開 SQLインジェクション攻撃への具体的な対策書
  • NoSQL登場の背景、CAP定理、データモデルの分類

    その例としてBeck氏自身が過去に取り組んできた生命保険会社のアプリケーションを例に挙げます。そのアプリケーションでは毎日のようにスキーマが変化するため、SQLORM(Object-Relational Mapping)では対応できず、オブジェクトデータベースのGemstoneを利用することで対応できたと述べています。 こうしたSQLだけでは満たせないさまざまな要件、上記の図にあるようにスキーマの可塑性、スケーラブルなデータ読み込み、書き込み、処理の柔軟性などを満たすために、リレーショナルデータベース以外のNoSQLな製品が開発された。これがNoSQLの登場の背景にあるとBeck氏は解説します。一方で、こうしたさまざまなNoSQLを、NoSQLという言葉で表すのは適当ではないという憂慮も示しています。 Here is where the futility of defining NoSQ

    NoSQL登場の背景、CAP定理、データモデルの分類
  • Key Value Storeについて

    主な3つの機能について実装状況を示してみました。 「データ永続化」とは、ストレージサーバを再起動してもデータが失われないようにデータをメモリではなくHDD等に格納できる機能です。例えば、memcachedはメモリにデータを置くため、ストレージサーバを再起動するとデータが失われます。 「データ冗長化」とは、格納したデータがストレージサーバ側で自動的に複数のストレージサーバにコピーが作られる機能です。1台(または数台)のストレージサーバがダウンしてもデータが失われることはありません。 「データ分散」とは、キーのハッシュ値等を元にデータの格納先のサーバを振り分ける機能で、負荷分散を図ることができる機能です。なお、memcached、Tokyo Tyrantにはサーバ側での分散機能はありませんが、クライアント側のライブラリによって格納先サーバを分散させることも可能です。 memcachedプロトコ

    Key Value Storeについて
  • MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場

    読み込み>書き込みなデータベースだと、実体化ビュー (materialized view) を使って読み込み速度を上げるってのは有効な手法 ちなみに MySQL や PostgreSQL だと実体化ビューはトリガーを使って書く *1 では、トリガーベースの実体化ビューを後から追加した場合に、どうやって既存データを新しいビューに反映させるのか。 UPDATE トリガを、ビューの側に対応するデータがない場合は INSERT トリガと同様の動作をするように実装すればいい (典型的には REPLACE INTO 文を使う)。ビューの初期データ充填は UPDATE src_table SET id=id; MySQL だと CREATE INDEX CONCURRENTLY がないから副インデックス作成はスレーブでやったりする*2けど、上の UPDATE を LIMIT つきで回すことで、ビューをイ

    MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場
  • 1