【PureJava】 Derby 1 【OpenSource】

レス数: 137

概要: よくわからん流れだなw
No.51
よくわからん流れだなw
No.52
もし全能の神が存在するとしたら、そのような神は常に邪悪であり信じてはいけない。
No.53
>>49

Derbyは、Pure Javaで書かれたデータベースの中では
飛びぬけて高機能だよ。
外部結合、view、制約、副照会、トリガー、ストアドプロシージャ
など、ほしいと思う機能のほとんどが使える。
No.54
ちょっと遅いけどね (゚∀゚)
No.55
つまり
>>43
のような位置づけになるのか?
欲張りたければDerbyを使えと?
それでよろし?
No.56
>> 55
何か機能に問題があるわけじゃないんだから、
とりあえず自分で一度使ってみれば?
使うの全然難しくないから。
No.57
ストアドプロシージャがあるのか
してその性能は如何に?
No.58
でるびー?
でるばい?
No.59
×でるびー
×でるばい
○ダービー
No.60
あいだとって
デービーでいいよ
No.61
Mustangスレによると、このApache Derbyが次世代Java
Java SE 6 Mustangに取り込まれるらしい。
これにはびっくりした。
No.62
組み込まれるのは事実だが、JDKに組み込まれることに注意。
JREじゃないからね。
No.63
VMに組み込まれrんじゃないのか・・・残念
No.64
>>62-63

VMに組み込まれると一体どんなメリットがあるんだ?
native実装による高速化にでも期待しているのか?
No.65
というかVMに組み込むってどういうことよ。
それってDellのPC(ハードウェア)にデータベース組み込むと言ってるのと同じでは。
No.66
というか、
WindowsにAccessが標準搭載、
みたいな感じがする。
まあJDK限定じゃ、開発用のおためしDBに
使ってねって感じなんですかね。
No.67
ですねえ。思い切ってJREに付属しちゃえば普及は加速しそうだし、
「JRE 6に付属したJava DBの使い方」みたいな記事も大量に書かれそう
なんだけど。
DBベンダーからの反発がきつくなりそうだから止めたのかな。
No.68
>>65

だからnative実装で高速化じゃないか?
それでは、100%PureJavaというApache Derbyの特徴を
妨害することになってしまうが。
今のところ、そのまま標準APIの一部として組み込んだほうがマシだな。
ネイティブで実装すると、各OS毎に実装するコストがかかりそうだ。
No.69
なぜデータベース「エンジン」という「環境」の話をしているのに「標準APIの一部として
組み込め」という話になるのか。
APIはちゃんとJPAで標準化されたでしょ。
No.70
>>69

よくみろ、
>>65
に対するレスだろう。
あの時点では
>>65
はデータベースエンジンの
話はしていないので
ああいう話になっても仕方がないだろう。
No.71
>>61-62

JDK内のファイルであっても再配布可なものもあるし、実際の
ライセンス見ないとな。
No.72
>>68

RDBMSをネイティブ実装して速くなるか?
ほとんどのケースで、かえって遅くなると思われ。
JNIを呼ぶコストはでかい。
そして動的最適化はRDBMSみたいなものに向いてる。
Derbyでクラスタリングができるようになったら、
RDBMSベンダは真っ青だろうな。
No.73
>>72

それはあーる!別にJava原理主義者じゃないけど。
No.74
weblogicでクラスタ組むときにderbyを使用すると勝手にミラーリング
してくれるのか??table情報とかも??
だったら凄いけど。
No.75
HSQLならMySQLやSQLite並に速いんだろ?
Java DBとして昇格したDerbyは準拠型、H2は性能型と住み分ければいいよ。
No.76
>>72

Java純度がほぼ100%近いNetBeansがネイティブに頼ってるEclipseに
速度面で勝ってしまったことからDerbyをネイティブ化
するのはかえって遅くなると言うことか。
No.77
純粋な実行速度だけなら、HotSpotの最適化技術は凄く効果的だから
遅くなるとすればI/O処理だと思われる
No.78
DerbyはPostgreSQL、HSQLDBとH2はMySQLと考えればいいんじゃね?
No.79
Updateは遅いが、Queryは良い線行ってる気がする。
「Embedded用途のなんちゃってDB」と言う認識で
使い始めたのだが、なかなかどうして優秀じゃん。
No.80
ほほう。selectは頑張ってるのか。
insertでぶっちぎりでHSQLに負けたから敬遠してた。
No.81
Apache Derby Performance
ttp://wiki.apache.org/apachecon-data/attachments/Us2005OnlineSessionSlides/attachments/ApacheCon05usDerbyPerformance.pdf
No.82
>>81

非常に良い資料だね。特に15pageあたりは興味深いよ。
No.83
Java6 betaにJDBC4.0対応のDerbyが入っていて、細々と実験中。
なかなか良い感じですな。
No.84
ij のrunコマンドでsqlファイルを読み込む場合、文字コードを指定することは出来ますか?
derby.ui.codesetオプションをつけてみたら、ijコマンド全体が文字化けしてしまいましたorz
No.85
データの挿入を今より高速化させたいのだが良い方法を
どなたかご存知じゃありませんか?
Statement#addBatch()
を使用しているのだが。この質問って、プログラムの方かな?
No.86
>>85

バッチ処理で希望のパフォーマンスがでないのなら
あきらめろとしかいいようがない。
JDBC使わずにネィティブにINSERTしろ
No.87
addBatchで追加する処理が1件とかそんなオチなんでは....
PreparedStatementは、パラメータ違い以外は同じSQLなのに処理毎にnewするなんて
愚かなことをしない限り結構高速に動く。
それをやったうえでまだ遅いというなら、ストアド・プロシージャ化するしかないんじゃね?
No.88
EclipseでEmbeddedドライバを使って
connection := DriverManager.getConnection("jdbc:derby:testDB;create=true",props);
stmt := connection.createStatement();
stmt.execute("CREATE ほにゃらら");
ってやったときに、DERBY_HOMEに関係なく、eclipseのインストールディレクトリ直下に
testDBのディレクトリがつくられます。どうやったらDBの作られる場所を指定できますか?
No.89
Properties props = System.getProperties();
props.setProperty("derby.system.home", "c:\\derby");
No.90
>>89

サンクス!
No.91
derbyでPLSQLを使うにはどうすればいいの?
No.92
OracleのDabaseLinkからDerbyに繋いでPL/SQLで…ってアホか!
No.93
DerbyにはPLSQL相当の仕組みはないのだろうか??
No.94
>>93

あってるかわかんないけどJavaで書けるんじゃないかなぁ。
>>81
のPDFをちょっと読んだ限りだと
PreparedStatementのSQLはコンパイルされてJavaのバイトコードなる
というあたりから、Javaで書ける仕組みがあってもおかしくないと思った。
No.95
ダービーにはストアドプロシージャあるからPL/SQL相当はいらんだろ
No.96
PL/SQLってOracleのストアドプロシージャじゃないの?
No.98
で、だ。
これを導入しようとしたら何か注意点はあるか?
No.99
>>96

違うよ。
No.100
まるで情報が蓄積されていないな。すでに終わってしまった存在なのか?