- PR -

ＤＢの選択

«前のページへ 1|2
投稿者投稿内容
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2004-10-11 22:16
引用:

unibonさんの書き込み (2004-10-11 17:54) より:
unibon です。こんにちわ。

ちょっと突飛な意見だとは思いますが、DBMS 位、自分で作れないものでしょうか。
＃「自分」って特定の人を指すわけではないです。



ＳＱＬを実装するのはむずかしいですが、特定のメソッドで、特定の処理ならば
それほど難しくはないです。

会社員
ベテラン
会議室デビュー日: 2003/01/21
投稿数: 50
投稿日時: 2004-10-11 23:59
メジャーというかシェアの高いものを使います。
理由は、解説本が多いし、Webの情報量も多いし、エンジニアもたくさんいるからです。
今だと、OracleかSQL Serverですかね。
iakio
会議室デビュー日: 2002/11/28
投稿数: 13
投稿日時: 2004-10-14 19:32
ちょっと趣旨をはずれるかもしれませんが、一応情報として、
引用:

Jittaさんの書き込み (2004-10-11 17:41) より:
　単に「安いから」では、もしもの障害発生時が大変です。たとえば、Oracleでは、REDOログによって、障害発生直前の状態まで復旧が可能です。しかし、PostgreSQLの場合、データをバックアップしたときまでしか戻せません。

この機能(PITR)は、PostgreSQL 8.0から実装されます。
(詳しくは「【PostgreSQLウォッチ】基幹業務向けに大幅拡張されたPostgreSQL 8.0，ベータテスト開始」を御覧ください)

引用:

　また、Oracleの場合、ディスクを最適化しながらデータを格納しますが、PostgreSQLの場合、削除したデータが入っていたところは「穴」になります。穴を埋めるコマンドもありますが、そのためにはデータベースを止めなければなりません。
（＠ITの記事より、そういうことらしい）

これは全くの誤解です。vacuumはデータベースを稼働したまま実行できるし
(逆にいえば動いていないデータベースに対してvacuumすることはできません)
7.2以降で実装されたコンカレントvacuumはselect,insert,delete,updateを
ロックすることはありません。
コンカレントvacuumを実行すると、その「穴」は最利用されるようになるので、
ファイルサイズが大きくなるに歯止めをかけることができます。
メンテナンス作業などで大量のバッチ処理を行った場合以外は、定期的な
コンカレントvacuumで十分でしょう。
上記URLの方が、vacuum fullが定期的に必要と主張されているのは理解できません。
ついでにOracleとの違いを言うと、PostgreSQLは追記型を採用しているので、
ロールバックセグメントが必要ないし、大量の行ロックが表ロックに
エスカレーションすることもありません。
カーニー
ぬし
会議室デビュー日: 2003/09/04
投稿数: 358
お住まい・勤務地: 東京
投稿日時: 2004-10-14 19:54
引用:

iakioさんの書き込み (2004-10-14 19:32) より:
ついでにOracleとの違いを言うと、PostgreSQLは追記型を採用しているので、
ロールバックセグメントが必要ないし、大量の行ロックが表ロックに
エスカレーションすることもありません。


Oracleにもロックエスカレーションはありませんよ。
それはMS SQL ServerとかDB2のおはなしです。
iakio
会議室デビュー日: 2002/11/28
投稿数: 13
投稿日時: 2004-10-14 21:07
引用:

カーニーさんの書き込み (2004-10-14 19:54) より:
Oracleにもロックエスカレーションはありませんよ。
それはMS SQL ServerとかDB2のおはなしです。

すいません。間違いました。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2004-10-15 21:21
引用:

iakioさんの書き込み（2004-10-14 19:32）より：

vacuumはデータベースを稼働したまま実行できるし
(逆にいえば動いていないデータベースに対してvacuumすることはできません)

　ああ、すみません。ここの「止める」は、「使用を止める」、つまり『VACUUM実行中はテーブルロックが掛かり、データベースの更新ができなかったり、パフォーマンスが低下するなどの問題もあるという。』にかけていました。

引用:

上記URLの方が、vacuum fullが定期的に必要と主張されているのは理解できません。

　Oracleの人だから、ということで・・・

引用:

この機能(PITR)は、PostgreSQL 8.0から実装されます。

　しかし、まだβですよね？「今、使うには躊躇する」という意味にとってください。Oracleもそうですが、１度マイナーチェンジするまで（8.1リリース版まで）怖いかな、と。


　１度使ってみましたが、PostgreSQLって、結構面白いですね。探しきれなかっただけかもしれませんが、ストアドプロシージャのデバッグなど、周辺アプリがそろえば（そしてWindowsから使いやすくなれば…って、8.0から対応？）、面白いかな、と。データ型の追加を、もう少し時間をかけたかった。が、そうすると、データ資産の他DBへの移設がしにくいし。。。
あつしfx
大ベテラン
会議室デビュー日: 2002/04/08
投稿数: 104
お住まい・勤務地: XPできるところ
投稿日時: 2004-10-16 13:49
規模が小さいので、MySQLかPostgreSQLが普通ですね。
会社員時代はOracleでしたけど。

ただ、最初から最適なDBが選択できるかというのは結構難しい問題だと思います。
システムにもよりますが、DBの切替がしやすいようにシステム開発をしておくというのがdベターでは？
_________________
http://aglabo.com/ @Homepage
http://furukawa-select.com/mt/ @Blog
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）