アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
それぞれの位置づけは? (スコア:0)
フリーの DB が大規模に使われたりするようになってくれば 必然的に PostgreSQL しかないんじゃないの?
# あ、FireBird があったか…
Re:それぞれの位置づけは? (スコア:3, 参考になる)
フリーで 24x7 な DB が当時(多分 5 年ぐらい前だと思います)なかったんです。
古い PostgreSQL では VACUUM ANALYZE している時は、
問合せ等に応答しないというのがネックでした。
VACUUM が必須だというのに。
# 更新/削除したレコードは削除フラグが付くだけで VACUUM まで削除されない
最近は VACUUM 中も応答するとの事なので、
このような不利な点はないでしょうが、
当時は、運用の難しさから敬遠した開発者は多いと思います。
個人的には
LAST_INSERT_ID() が無い所が嫌いです。
バックアップでトラぶった事がないのが好きです。
日本では「シーラカンス
Re:それぞれの位置づけは? (スコア:1, 参考になる)
例:
table: hogehoge
id serial
name text
insert into hogehoge (name) values ('baka') returning id;
みたいにすると、idが取得できます。
Re:それぞれの位置づけは? (スコア:1, 参考になる)
ってことはこれは関係ないですね
transaction関係ないってのは、複数DBで同じsequenceを使いたいときか、
二相コミットとか難しいことしなくてもいいので楽ってのはありますね
まー、欠番が出るのがもったいない(気持ち悪い)ってのもなんとなくわかりますが。
もし、欠番が嫌だったら自分でtriggerで実装するという手もありですね。
Re:それぞれの位置づけは? (スコア:0)
そんなめんどくさいことするぐらいなら、
欠番ぐらい捨ててもいいんじゃない?
ってところであきらめないところがアレゲですね。
普通はどうでもいいのであきらめるんですが。