Visual Editor - EclipseThe Eclipse Data Tools Platform™ provides extensible frameworks and exemplary tools, enabling a diverse set of plug-in offerings specific to particular data-centric technologies.
uebu: JDBCのRowSetを使う
RowSetは、JDBCで伝統的に使われているResultSetインターフェースを拡張したものです。 JavaBeans的なプロパティを持ち、 結果集合の他に、データベース接続情報やSQL文も内部に持つことができます。 つまり(Statement+ResultSet)のようなものです。 RowSetは最も基本的なインターフェースで、 それを発展させたサブインターフェースが性質によって幾つか提供されていますが、 最も特徴的な性質を持つのはCachedRowSetというインターフェースです。 これは、ResultSetや他のRowSetのサブインターフェースと異なり、 「DB接続を保持しておく必要がない」という特徴を持ちます。 ResultSetに格納した結果集合は、DB接続を終了すると失われてしまいます。 そのため、たくさんのクライアントからDBアクセスがある一般のWebアプリケーションでは
ActiveRecordでユーザの最新の発言を取得する - Okiraku Programming
id:NeoCat:20080525に引き続き monologue (Twitterもどき)を作っていきます。 特定のユーザの最新の発言を取得するにはどうすれば良いでしょうか。 まず思いつくのは、そのまま「あるユーザのステータスを日付順に並べたときに、一番最初のもの」と記述する方法です。 findで書くと下のような感じでしょうか。 new_status = Status.find(:first,:conditions => [ "id = ?", @user.id], :order => "updated_at DESC") もしくはfind_byで new_status = Status.find_by_user_id(@user.id, :order => "updated_at DESC", :limit => 1) など。 しかし、例えばフォロワーの一覧に最新ステータスを並べたい場
「MySQL，PostgreSQLとFirebirdの性能をユーザー会メンバーが徹底比較，判明...
「更新とJOINが多ければMySQL，シンプルなSELECT主体ならPostgreSQLが向いている。ストアド・プロシージャでシングル・コネクションならFirebirdは非常に速い」---6月23日に開催された「オープンソースカンファレンス2007.DB（OSC2007.DB）」で，各オープンソースDBのコミュニティのメンバーによる性能比較が披露され，従来の一般的なイメージとは異なる“意外な結果”が明らかにされた。 オープンソースカンファレンスは，オープンソース関連コミュニティが主催するイベントで，OSC2007.DBはデータベース関連のコミュニティが集まったイベントである。性能比較セッションを担当したのは，日本MySQLユーザ会の堤井泰志氏，日本PostgreSQLユーザ会の片岡裕生氏，Firebird日本ユーザー会の木村明治氏。「あくまでボランティアによる性能比較であって，最速，最新マ
suVeneのあれ: PL/SQL等のバッチ処理でたまに見かける最悪なプログラム
2007年01月18日 PL/SQL等のバッチ処理でたまに見かける最悪なプログラム 今日はプログラムの話 & 愚痴。 DB更新などのバッチ処理で Pro*C 使ってたり PL/SQL 使ってたりするプロジェクトは結構多いが、あほかっ！と思ってしまうことがある。ソースが汚いとか main() や BEGIN END の間に全部の処理書いてるとか、そういうのはまだ我慢できる(ていうか、全部直してる訳にはいかないので)。では、何が気に食わないのかと言うとループ中にファイルにアクセスする感覚で SELECT 句発行してたりするプログラムが結構多いこと。 ちょっと考えればわかるだろう！とか、仕様はどうなってんだ！とか、ソースレビューの段階で気づかないか？とか色々意見はあるだろうが、ちょっと大きめのプロジェクトなどでコーディングを丸投げしたり、プロジェクトに火がついてプログラマ大量投入して解決、みたい
[pgsql-jp: 29026] Like を使った前方一致検索時のインデックス使用条件について
Hajime Lucky Okada pgsql-jp@ml.postgresql.jp Thu, 13 Feb 2003 17:28:33 +0900 前の記事: [pgsql-jp: 29022] Re: VBA+ODBCでトランザクションを行うには 次の記事: [pgsql-jp: 29027] Re: Like を使った前方一致検索時のインデックス使用条件について 目次の順: [ 日付 ] [ スレッド ] [ 件名 ] [ 発信者 ] こんにちは、岡田と申します。 お世話になっております。 表題の件に関し、非常にシンプルなテープル構成に関わらず 使用／設定方法が悪いのか、人間の期待した動きをしてくれません。 それは、ある単一カラムの % を使用した前方一致の検索です。 次に示す検索対象カラム mitumori は、text 型で実質 全て 6 桁の英文字、 高々 1 万件程度です
naoyaのはてなダイアリー - MyISAM vs InnoDB
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
Tags: Database schemas
An online tech community is the most exciting place for a software developer to spend their time. It not only offers the chance to work and interact remotely, but also helps in honing one’s own skills and becoming a well-rounded programmer. Whether you are a budding software developer or simply passionate about technology, here are the best online software development communities you can join. The
MySQL 文字化け問題を本気で直す
mysql> status; -------------- mysql Ver 14.7 Distrib 4.1.20, for redhat-linux-gnu (i386) using readline 4.3 Connection id: 36 Current database: staff2006 Current user: maiha@localhost SSL: Not in use Current pager: lv Using outfile: '' Using delimiter: ; Server version: 4.1.20 Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: latin1 Db characterset: latin1 Client char
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
