PostgreSQL or MySQL

[191:>190 (2000/10/24(火) 10:28)]
こりゃまた、貧相な煽りだな。

煽りでもなんでもいいから他人との接点が欲しいんだな…
寂しいヤツ。

[192:55,57,58,171 (2000/10/24(火) 17:25)]
現在、InterBaseとPHP4でWebアプリを作っていますが、
今後のアクセス数の増大とデータの大容量化には
勝てそうにありません、
リアルタイムに内容の変わるDBで、
内容の全く同じDBを別々のサーバで検索とか無理ですかねぇ、
色々逃げ道調べたんですが、無いんです。(オラクルのみ対応(泣))

例えばrsyncとかでDBのファイルを１分間に４回ぐらい
別々のサーバにコピーしてから検索処理とか、(読み取り専用だし)
こんな単純でバカな方法でも構わないのですが、
実績とか無いかなぁ、

[193:>192 (2000/10/24(火) 18:24)]
どんなシステムなの?
読み取り専用ならインデックス張りまくっちゃえ(無責任)

似たような話がInpriseのケーススタディにあったよ。参考になるかな?
http://www.inprise.co.jp/interbase/cases/ib006.html

[194:192 (2000/10/24(火) 19:15)]
あぁぁぁ、そうだ！、
バカだ、、＞私

>>193
すいません、お手数かけました、、
その都度（更新処理×？台）やればＯＫなんですね、
今回のが済み次第テストしてみます。(振り分けは大変そう、、)
オラクル買ったらサーバなんて何台も買えますし、

個人が色々できるグループウェア的な
システムって事しかまだ言えません(申し訳ない)
画像が多いのと、個々のデータ量が多いのと、
何より登録数が超多いという、、、＜意味不明だ

[195:> 189 (2000/10/25(水) 00:03)]
180です。
想定してるシステムの前提を言ってなかったので、
すれちがってたのかもしんない。スマソ。
俺はBtoCやBtoBを想定してたんだ。

> Perl + DB_Fileなんて実によくあるパターンじゃないか。

個人的なもんであればあるだろうな。

> いったいWeb上でなにする気?
> たかだかCGIにそんなもん持ち出すほうが変だろ。

先にも言ったが、俺はBtoCやBtoBを想定してたんだ。
だから、データの不整合に発生させない仕組みをDBMSを使わずに
手で作っちゃうのか？
っていってたんだよ。

[196:> 189 (2000/10/25(水) 00:12)]
180です。
190 の発言は、俺じゃねーかんな。
俺もああいう煽りは好きになれねぇ。

[197:名無しさん＠お腹いっぱい。 (2000/10/25(水) 00:25)]
Ｃと、一般ファイルと、せまふぉ使えや。

[198:名無しさん＠お腹いっぱい。 (2000/10/25(水) 04:59)]
元々から仕組みだけはしっかり考えておかないと、拡張していくうちに
破錠するシステムは多いやね。
それこそ「perl+DBでちょいちょい。開発速度速いし、それで十分ダロ」
なんて言ってる所にそのパターンが多い。たぶん195もそういう辺りの
事を言ってるんだと思うが。

ちゃんと知識ある奴が「今はそこまで厳密にやる必要ない」と考えて
やってるなら話は別だけどね。

[199:名無しさん＠お腹いっぱい。 (2000/10/25(水) 09:42)]
>元々から仕組みだけはしっかり考えておかないと、拡張していくうちに
>破錠するシステムは多いやね。
そういう考えでド田舎の高校や役場のORACLEサイトが
税金何千万円も投入して構築されているんだな。
で、利用者一日数人だったりする。

[200:名無しさん＠お腹いっぱい。 (2000/10/28(土) 04:29)]
>そういう考えでド田舎の高校や役場のORACLEサイトが
>税金何千万円も投入して構築されているんだな。

それは、Oracleが問題なんじゃなくて、
あんたのいうド田舎の高校や役場が悪いだけなんじゃないの？

システム組んで商売してる側からしたら、
ユーザサポートがあるDB突っ込んだ方が何かあった時、
なにかと楽だろうよ。
趣味でシステム組むわけじゃないからな。

自分でしこしこ作る、触る部分をできるだけ少なくしておく
これシステム構築でもプログラミングでも基本だと思うが。
あ、これは商売の場合の話ね。

自分でサーバ立てるんだったら話は全然違う。（金出してDB使おうとは思わん）

read.cgi ver5.26+ (01/10/21-)