■掲示板に戻る■ 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 最新50



レス数が1000を超えています。残念ながら全部は表示しません。

PostgreSQL or MySQL

1 :名無しさん :2000/04/12(水) 19:03
Apache+PHP/FIで検索システムを作ろうと思っています
PostgreSQLとMySQLのどちらがおすすめですか?
ご意見きかせてください
規模は小さいです&日本語必須です
サーバはLinux(Vine)を考えています


747 :746 :02/10/21 19:17
自己レスです。varをchownしたら無事起動しますた。
/usr/local/mysql/bin/mysql_install_db
chown -R mysql.mysql /usr/local/mysql/var/ <これ
/usr/local/mysql/share/mysql/mysql.server start --user=mysql
失礼しました〜〜

748 :名無しさん@お腹いっぱい。 :02/10/22 17:09
教えて下さい、
PostgreSQLにて、月末日を求める関数とかあるのでしょうか?
例えば、2002年10月だったら31とかって意味です。
たしか、Oracleにはあったと思うのですが、
PostgreSQLでは探し出せません、
やはり、自前で関数を書いたりするのでしょうか。(涙

あと、日付の加算減算?等は可能なのでしょうか?
例えば、2002-10-15 の、前年同日のデータとか参照したりする場合に
利用したいのですが。

749 :名無しさん@お腹いっぱい。 :02/10/22 18:21
>>748
アプリ側で処理したら? 言語は何? 大抵はライブラリが揃ってるはず。


750 :名無しさん@お腹いっぱい。 :02/10/22 18:37
>>749
DebianWoodyにインストールした PostgreSQLにDelphiからPQCompoで繋いでいます。
で、なんとか解決しましたので、一応自己レスしときます、
但し、かなり汚くて正しいやり方があるのか無いのか解りませんが・・・。

select
to_char('2002/10/20'::DATE - '1 Year'::interval ,'YYYY-MM-01') as 前年同月,
to_char('2002/10/20'::DATE - '1 Month'::interval ,'YYYY-MM-01') as 前月,
to_char(now() + '1 Day'::interval ,'YYYY-MM-DD') as 明日,
to_char('2002/11/01'::DATE - '1 Day'::interval ,'YYYY-MM-DD') as 月末日;

751 :_ :02/10/24 16:58
みなさま、教えてください。
LINUXとPHP、MySQLでサーバを立てようと考えています。
MySQLってマルチCPUは対応しているのですか?
またCPU何台までOKですか?

本当にCPU増やすだけで性能って上がるものかしら。

752 :名無しさん@お腹いっぱい。 :02/10/24 21:48
>>751
MySQLはtheadを使って処理するからLINUXにおけるthreadの扱いによる。
threadベースでCPUに割り振られるならSMPにすると速くなるんじゃないかな。
また、いくつまでのCPUに対応しているかもそのOSの対応状況によるもので、MySQL自体に依るものではないと思う。

というわけで、あとはLinux板に行ってLinuxにおけるthread対応について聞け。


753 :751 :02/10/25 10:16
>>752
アリガトウ

754 :名無しさん@お腹いっぱい。 :02/10/26 12:04
>>751
thread対応がわかったのなら、
あとは平均の同時実行SQL数でCPU枚数決めちゃうっていう手があるね



755 :名無しさん@お腹いっぱい。 :02/10/26 16:29
つか、クエリの実行をパラレルに処理できるならともかく、
ふつーCPU枚数増やしたところで一つのクエリの処理性能が
向上することはないと思うけど。>751

同時に処理可能なトランザクションの数は増えるだろうけど。

でも、それはthreadかprocessか、とかには関係ないと思うし。


756 :名無しさん@お腹いっぱい。 :02/10/29 23:45
mysql4 GCC3.2でmakeできたヤシいますか?

757 :名無しさん@お腹いっぱい。 :02/11/02 13:40
>>755
ちょっと待って
普通セッション管理/SQLエンジン/バッファ管理/リーダ/ライタ/ログは独立して動いていると思うのだが・・・
まさかPostgresとかMySQLって全部1スレッド上で展開されてるの?

758 :名無しさん@お腹いっぱい。 :02/11/09 02:50
PostgreSQLのSQL文で変数って使えないでしょうか。
関数だと $1 とか使えますよね、あんな感じで良いのですが。

759 :名無しさん@お腹いっぱい。 :02/11/09 04:49
>>758
つかえますよ。

例:
$I = select col from tbl;
while($I.next) {
 update tbl set col2=$I where col=$I;
}


760 :名無しさん@お腹いっぱい。 :02/11/09 22:31
>>758
>>PostgreSQLのSQL文で変数って

普通のSQLでは使えません

761 :名無しさん@お腹いっぱい。 :02/11/09 23:46
>>758
意味不明。変数があると仮定したSQLを書いてみたまえ。

762 :名無しさん@お腹いっぱい。 :02/11/10 02:59
>757
何をもって「普通」と言っているのか謎ですが。
それに「リーダ/ライタ」って何ですか?

基本的にバッファなど共有すべきものは共有メモリに入ってるし、
セッションを張るたびにインスタンスが一個起動して、
そいつが共有メモリを使う。

統計情報取るプロセスは別に存在してますけど。

これはPostgreSQLの話。MySQLは知らん。


763 :名無しさん@お腹いっぱい。 :02/11/15 00:18
MySQLの標準内部文字コードを SJIS にした場合のデメリットって
何かありますか?

764 :名無しさん@お腹いっぱい。 :02/11/23 00:58
>763

なにかトラブったときに真っ先にそこが疑われる、
というデメリットが。

765 :名無しさん@お腹いっぱい。 :02/11/23 02:29
>>763
逆に聞きたいが、SJISにした場合のメリットって何?

766 :名無しさん@お腹いっぱい。 :02/11/23 08:10
IBM拡張漢字を使用できる

767 :名無しさん@お腹いっぱい。 :02/11/24 03:41
IBM拡張漢字を表示できない機種を排除したwebアプリが作れる

768 :名無しさん@お腹いっぱい。 :02/12/11 02:20
PostgreSQL-7.3とMySQL-4.0でちゃんとしたパフォーマンス測定を
してそうなサイトってありますか。どうもPostgreSQL 6の時代に
ひどい目に遭ったオサーンはボロクソにいってるようなんですが、
それっていまもそうなのかな……


769 :名無しさん@お腹いっぱい。 :02/12/14 21:05
6.xの時代と今とではパフォーマンス全然違いますよ。
トランザクションログが実装されましたんで。


770 :名無しさん@お腹いっぱい。 :02/12/17 05:37
んで、MySQL も innoDB のおかげでトランザクション処理を可能にしたし
大規模 DB でのパフォーマンスも上げてきたしね。

しっかし、MySQL 4.0 のリファレンスマニュアルにある
For the upcoming MySQL Server 4.x releases, expect the following features
now still under development:

Mission-critical, heavy-load users of MySQL Server will appreciate the
additions to our replication system and our online hot backup.
Later versions of 4.x will include fail-safe replication; already existing
in 4.0, the LOAD DATA FROM MASTER command will soon automate slave setup.
The online backup will make it easy to add a new replication slave without
taking down the master, and have a very low performance penalty on
update-heavy systems.
って本当かいな。

771 :名無しさん@お腹いっぱい。 :02/12/19 02:28
PostgreSQLのバキュームについて教えてください。

当方6.5.?なので、バキュームは非常に不安定です。
また、バキュームだけではインデックスは作り替えてくれません。
ですので、代わりにDBのメンテとして
pg_dumpでバックアップし、dropdb,createdbをして
psqlで復元するという方法を使おうと思うのですが、
問題ないですか?
(一度バキュームでDBが壊れたことがありますので。。。)

772 :名無しさん@お腹いっぱい。 :02/12/19 02:46
7.2 以降にして
vacuum analyze
するのはどうでしょ。運用中でも止める必要はないし。
遅くなるけど。

バックアップして戻すのは別な次元の話だと思う。

773 :名無しさん@お腹いっぱい。 :02/12/19 03:07
ありがとうございます。バージョンアップなどは
ちょっと不可能です。
お客さまのサーバだし、他のソフトとの絡みもあるし。

バックアップから戻すと、結局バキュームと同じ効果があるらしいのです。
それも危険ですかね。。

774 :名無しさん@お腹いっぱい。 :02/12/19 03:39
6.5.3 にして vacuum


775 :771 :02/12/19 23:57
35 :29 :2001/06/14(木) 18:02 ID:???
環境。
Apache/1.3.20
PHP Version 3.0.18-i18n-ja-2
PostgreSQL 6.5.3

38 :名無しさん@お腹いっぱい。 :2001/06/18(月) 00:16 ID:4Y6BFwKU
>>35
そのPostgreのバージョンはvacuumするとデータが壊れちゃう
バージョンだけど、そのせいじゃないの?

vacuumかけると、データが壊れるらしい。。。





とあります。私のもそうです。

776 :名無しさん@お腹いっぱい。 :02/12/20 03:06
ていうか、MySQLの本家のML読んでると、データが壊れたとか無くなったとか、
そういう話ばっかりなんですが、おまいら、本当に業務系で使えますか?


777 :名無しさん@お腹いっぱい。 :02/12/26 09:18
PostgreSQL7.3 PHP4 REALbasic4.5.2 MacOSX10.2.3でデーターベースを作成してます。
そこで、JPEG画像を使ったdbも作成しようと考えているのですが、PostgreSQL側に
どんなタイプでどういう風にすればいいのか教えて下さい。

778 :bloom :02/12/26 10:03



http://www.agemasukudasai.com/bloom/

779 :名無しさん@お腹いっぱい。 :02/12/26 12:00
>>777
でっかいバイナリデータをLOB型としてDBに入れるか、ファイルとして保存
するかは悩ましいところですよね。


780 :名無しさん@お腹いっぱい。 :02/12/26 12:14
>>779
ヲレ的に中身までなめる必要がないものを DB に入れるのにはものすごく抵抗がある。
ただ、ファイルにすると PostgreSQL だけで管理が完結しなくなるのでちょっと
面倒になるけど。

781 :  :02/12/29 19:15
>>780
ファイルパスだけの管理にとどめて、実ファイルはバッチ的にサクっとやっちゃうという手法とればよいよ。
(旧ファイルパスの情報をselectしてファイルを削除
 →成功したら旧ファイルパスの情報をdelete
  ファイルがなければ成功扱いとする
 これを1ファイルごとにcommitしながらやる)
って、銀行のオンライン処理っぽくなるのでメンドーだけど。


782 :名無しさん@お腹いっぱい。 :02/12/29 21:43
>>777
Base64でエンコードして TEXT 型で保存してる。
ラージオブジェクト使った事もあるが、
トランザクションブロックにしなくちゃならなかったのでやめた。

最初は base64じゃなくて uuencode でも使おうかと思ったが、
エスケープしなきゃならない文字が出てきてしまうのでやめた。

783 :名無しさん@お腹いっぱい。 :02/12/31 01:14
>>781
それがまさに「PostgreSQL だけで管理が完結しなくなる」ってことやん。
実データの commit や delete などを DB 以外の場所で行うんだから。

784 :名無しさん@お腹いっぱい。 :02/12/31 01:57
>>780
どのRDBMSもLOBはそれに適した実装になっているはずだから、あまり
抵抗はないなぁ。TEXTに突っ込むのはちょっと乱暴だと思うけど。
Postgresの場合、結局のところ>>781をDBMSの管理下で行うような
実装になっていたよね。

785 :名無しさん@お腹いっぱい。 :02/12/31 02:06
psqlコマンドラインからのクエリは成功するのに
Pg使ってPerlで$conn->exec("$query")するとPGRES_FATAL_ERRORになります。
クエリはselect * from table where keyword='hoge'くらいの単純なものです。
こういう場合のデバッグってどうやったらいいですか?

786 :名無しさん@お腹いっぱい。 :02/12/31 09:31
>>785
$conn->errorMessageは見た?

787 :名無しさん@お腹いっぱい。 :02/12/31 12:58
>>786
ありがとうございます。
アクセス権の設定のミスでした。

788 :名無しさん@お腹いっぱい。 :02/12/31 16:00
http://wuffs-moviedb.sourceforge.net/
http://vcdphp.codehack.de/
みたいなソフトってmysql対応のものばっかだけどやっぱ
海外ではmyが主流なんだね。。

789 :779 :03/01/01 00:26
>>784
普段はDBに格納しておくとして、ファイルシステム上に存在しているほうが
処理しやすいデータの場合にも対応できるのでしょうか。


790 :名無しさん@お腹いっぱい。 :03/01/01 01:15
ファイルシステム上に存在している方が処理しやすいというのはどういうのだろう?
DBMSを介さずに他のプログラムからアクセスしたいとか、ランダムアクセスしたい
とかいう場合はLOBは向いていないと思うが。

791 :名無しさん@お腹いっぱい。 :03/01/06 23:32
>>782 のやり方のいいところは、pg_dump で何も考えなくても
他のマシンに DB をエクスポートできることかな。

792 :名無しさん@お腹いっぱい。 :03/01/08 15:44
>>782 >>791
textに突っ込むくらいならbytea型でやればいいと思うんだが。

どちらでやろうが、select時にlibpqが大量のメモリを必要とする。
いまどき画像ファイル程度で簡単にはメモリ不足にならんだろうが、
あまり大きい結果セットにならないように気をつけようね。

793 :名無しさん@お腹いっぱい。 :03/01/08 16:15
>>790
DBMSを介さずに他のプログラムからアクセスしたいっていうのは、
web システムなんかじゃよくあるシチュエーションじゃないか?

794 :792 :03/01/08 22:55
>>793
WebだとApp鯖がクラスタ構成とることが多いから、DBで集中管理しつつ、
各ノードに必要に応じてローカルファイルとして展開するってのが一般的では?

795 :名無しさん@お腹いっぱい。 :03/01/08 23:21
>>793
だからLOBにするかしないかってのは要件次第ってこと。

796 :名無しさん@お腹いっぱい。 :03/01/09 11:41
>>794
web サーバに SAN なり NFS なりでファイルシステムをマウントすることもあるぞ。

797 :名無しさん@お腹いっぱい。 :03/01/10 04:28
PostgreSQLのpostmasterが動いてるマシンを
nmapでポートスキャンしてもサービス検出され
ないんだけどそんなもん?

798 :gn355my0 :03/01/10 10:04
>>797
起動オプションによってはそんなもん

799 :798 :03/01/10 10:08
>>798
うわ、スレ違いレスにて解決してたとは。。。スレ汚しスマソン

800 :山崎渉 :03/01/15 13:00
(^^)

801 :名無しさん@お腹いっぱい。 :03/01/15 19:57
commit って辞書で引いてみたら。。。

・犯す
・(悪いことを)する
・精神病院に入れる
・陥れる
・束縛する
・困難な立場に立たせる

って。。。
なんで commit なんて単語採用したの?>SQL作った人

802 :名無しさん@お腹いっぱい。 :03/01/15 21:26
>>801
元には戻せないようにする、確定させるというつながりじゃないかな。


803 :名無しさん@お腹いっぱい。 :03/01/16 00:28
>>801の辞書が偏ってるだけだろ....

804 :名無しさん@お腹いっぱい。 :03/01/16 00:40
[commit]のEXCEED英和辞典からの検索結果 
com・mit ● 
vt. (-tt-) 犯す (〜 suicide [a crime, an error]);
 委託[委任]する (to);
 (獄・精神病院に)入れる;
 陥れる (to);
 束縛する (〜 oneself to do [to a promise]);
 困難な立場に立たせる

WebGrep for EDICT (英和辞典兼和英辞典)
モナシュ大学(オーストラリア)Jim Breen氏のEDICTを検索します。
検索結果
640: へまをやる /to commit a blunder/
4594: 演じる [えんじる] /to perform (a play)/to play (a part)/to act (a part)/to commit (a blunder)/
8367: 強盗をはいる [ごうとうをはいる] /to commit a robbery/to burgle/

ttp://server27.hypermart.net/koro02/i/etoj/
検索結果
commit
に掛かり合う;犯す;を委任する;を収容する


805 :名無しさん@お腹いっぱい。 :03/01/16 02:14
>>801
チミは「コミットする」って言い回しを日常的に使わないのか?

806 :名無しさん@お腹いっぱい。 :03/01/16 03:23
日常的にですか!?
僕は使いませんけど、ひょっとして貴方様は強姦魔ですか?

807 :名無しさん@お腹いっぱい。 :03/01/16 03:45
オレもたまにコミットする。
その辞書に、comitter contributorって載ってないかな?

808 :名無しさん@お腹いっぱい。 :03/01/16 04:05
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?sw=2&MT=%83%52%83%7E%83%62%83%67

809 :名無しさん@お腹いっぱい。 :03/01/16 10:35
http://dictionary.reference.com/search?q=commit
> 4. To consign for future use or reference or for
> preservation: commit the secret code to memory.


810 :  :03/01/23 00:56
commitが日常会話的につかえない単語になってしまうのであれば、、、

omitやpermitやsubmitの立場がなくなってかわいそうじゃないか!!
文句あんならIBMにいって当時の4GL技術者とっちめてこい

811 :名無しさん@お腹いっぱい。 :03/01/23 09:49
>806
その理屈でいくと、日産のカルロスゴーンは、
社員に「強姦」を求めたことになってしまいますが。


812 :名無しさん@お腹いっぱい。 :03/01/23 15:33
実際にロト6の当選数字をDB化している人いるかな

813 :名無しさん@お腹いっぱい。 :03/01/25 11:23
>>812
いるとしたら、この板だな。
http://natto.2ch.net/denpa/

814 :名無しさん@お腹いっぱい。 :03/01/28 17:46
あのぅちょっとお尋ね申し上げますが。

ネームサーバのバックエンドとして PostgreSQL または MySQL を用いた実装とかって
ないでしょうかね?

要はリクエストに対し、DBに問い合わせる、みたいな。
キャッシュとかもちゃんと考えられてるとうれしいかな。

815 :名無しさん@お腹いっぱい。 :03/01/28 22:44
>>814
BIND9からその機能が入るんでなかったかな?
--with-dlz-fooでfooをバックエンドのDBとしたものができるはず。
ただ、素のBIND9に比べて遅過ぎて使い物にならないという噂を聞いたことがある。


816 :名無しさん@お腹いっぱい。 :03/01/31 01:21
(責任上)〔特定の目的・責務を〕引き受ける; 〔…を〕約束する

と、わしの辞書にはあるのだが・・・。

817 :名無しさん@お腹いっぱい。 :03/02/02 05:41
いまmysqlのクライアントいれてみました
どっか公開mysqlサーバないですか?
とりあえずコマンドの勉強だけでいいのですが

818 :vvv :03/02/02 06:04
http://jsweb.muvc.net/index.html
★☆★幸福になりたーい!!★☆★

819 :名無しさん@お腹いっぱい。 :03/02/02 11:24
      ,一-、
     / ̄ l |   / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    ■■-っ < んなーもなーない
    ´∀`/    \__________
   __/|Y/\.
 Ё|__ | /  |
     | У..  |


820 :名無しさん@お腹いっぱい。 :03/02/03 03:58
ディスクに余裕ないし、NetVaultは高価で手が出ませんが
MySQL,PostgreSQLで、DLTなどのバックアップ装置に直接dumpする方法ありませんか?


821 :名無しさん@お腹いっぱい。 :03/02/03 11:11
MD5ではなく、Cryptによって変換されたパスワードのリストをMySQLのユーザーに再利用したいのですが、MD5以外のパスワードは利用出来ませんか?

822 :名無しさん@お腹いっぱい。 :03/02/03 11:19
アクセスにしとけ

823 :名無しさん@お腹いっぱい。 :03/02/03 12:43
>>820
DLT って デバイスファイルに出てこないの?
/usr/local/pgsql/bin/pg_dump db_name -b -o -Fc > DLTへのパス
じゃダメ?

824 :名無しさん@お腹いっぱい。 :03/02/03 15:32
>>823
tar形式のファイルには落とせるね
でも8GB制限があったよ。
今は解決しているのか不明

825 :名無しさん@お腹いっぱい。 :03/02/04 02:46
さっきpostgreSQL入れてみました
sqlのを知りたくていれてみたのですが
いまいちしっくりくるデータがないですね
友達アドレス帳はabookで足りてるし
ってかわざわざdbms使うよーなことでもないけど
皆さんで私用でつかう場合はどんなことに使ってるの?

826 :名無しさん@お腹いっぱい。 :03/02/04 02:48
ついでにあげとくか

827 :名無しさん@お腹いっぱい。 :03/02/04 03:12
>>826
ISAMの代わり。

828 :名無しさん@お腹いっぱい。 :03/02/04 16:48
SELECT検索で, 該当レコードが 1000をこえたらそこで検索終了, みたいな処理は
MySQLまたはPostgreSQLでできるんですか?

829 :名無しさん@お腹いっぱい。 :03/02/04 20:41
limit 1000


830 :名無しさん@お腹いっぱい。 :03/02/08 22:22
PostgreSQLで, 表を結合した場合とか, 副問い合わせをいれた場合とかの検索に
必要な時間量とかを解説した本はないですか?

831 :名無しさん@お腹いっぱい。 :03/02/08 22:33
>>830
テーブル設計によって千差万別。
まずは EXPLAIN ANALYZE から始めたら?

832 :名無しさん@お腹いっぱい。 :03/02/08 22:36
>>830
MLでも言われていたけど、バージョン毎に結構挙動が違うんで、本にする
勇気のあるヤシはいないんじゃないかな。
Amazonで洋書を探してみても、そこまで踏み込んだものは見当たらない。

Oracleなんかのチューニングの本にはわかりやすい本も多いから、それを
参考にexplainの内容を自分で読み解くのがいいかも。

833 :名無しさん@お腹いっぱい。 :03/02/08 23:32
>>825
そんなあなたには、郵便番号DB
http://www.post.yusei.go.jp/newnumber/index.htm

少しは遊べるかも。量もたっぷりあるし。

834 :名無しさん@お腹いっぱい。 :03/02/09 06:38
あ  げ

835 :830 :03/02/09 14:09
>>831, >>832
EXPLAINでの分析で実用上は大丈夫なんですが, もう少し技術的に内部動作的な事が
知りたいんですが, バージョン毎に結構違うんですか・・・

本屋とかで見かけるチューニングの本は, プログラマにとっては内部動作考えれば
そんなことあたりまえだろ的なことがほとんどなんであまり役に立たないことが多いです.
なにかおすすめの本ってありますか?

836 :名無しさん@お腹いっぱい。 :03/02/09 17:26
>>835
DB 全般についての経験があるって前提で、
Postgres 固有のチューニング手法や
システム内部の情報について知りたいってことか。

本家の pgsql-performance メーリングリストとかはどう?
あとは ソースを読むしかないんじゃないのかなあ。

837 :名無しさん@お腹いっぱい。 :03/03/01 12:26
ヲイラのような、コードを読み書きしないイパーソUNIXユーザにとって、
オープンソースのRDBMSを使う利点って何ですか?
 - コスト
でも欠点はいくつも見えるんですよね。
 - レプリケーション
 - PITR
 - トランザクション(あっても透過的でない)


838 :名無しさん@お腹いっぱい。 :03/03/01 12:44
そんなことよりFirebirdをIRIXに移植してくれ。

839 :名無しさん@お腹いっぱい。 :03/03/01 13:24
>>837
商用DBだと商品が身売りされたりしていつのまにか消えてなくなったりする
リスクが回避可能。
つーか、やっぱり最終的にはソースを読む気になれば読めるってのが最大の
メリットじゃないの?
そこにメリット感じないならオラとか使うのが吉じゃないかな。

840 :名無しさん@お腹いっぱい。 :03/03/01 13:59
>>839
ヒゲみたいなセリフだな。
自分でソースをいじらない人にとってはリスクは一緒だよ。
オープンソースでも、開発者が興味を失って放棄される
リスクはあるわけだし。

841 :名無しさん@お腹いっぱい。 :03/03/01 14:07
>>840
多くのユーザを囲い込んでるプロジェクトなら、
元開発者のモチベーションがどうであれ、
延命の可能性はあるでしょう。リスクは相対的に低くなる。

842 :名無しさん@お腹いっぱい。 :03/03/01 14:27
>>837
いまさらトランザクションを問題にしているとは…。きちんと情報集めてる?

843 :名無しさん@お腹いっぱい。 :03/03/01 14:29
>>841
そんなの商用製品の場合も一緒だって。
ユーザーが多い製品なら、会社が身売りされたとしても
ほとんどの場合いきなり製品が無くなることはないだろ。
Rdbだっていまだにサポートされ続けているんだぜ?

844 :837 :03/03/01 14:38
>>842
問題ではないのですか?


845 :名無しさん@お腹いっぱい。 :03/03/01 16:26
postgresはフリーだけどトランザクションサポートされてるよ。


846 :837 :03/03/01 18:29
>>842 >>845
「トランザクションがサポートされている」こと自体が問題
ではないことぐらいは分かってますよね?



次100 最新50 (10:00PM - 03:00AM の間一気に全部は読めません)

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