パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

PostgreSQL + SymfoWare = PostgreSQL Plus」記事へのコメント

  • えー、そもそもSymfoware自体見たことがないので、実際の評価のところを聞きたいと思うのですが>識者の方々

    私としては、よくPostgreSQLはVACUUMが・・・といいますが、VACUUMを必要としないデータベースのほとんどはロールバック処理が大変なことが多く、それに対してPostgreSQLでは逆にロールバックが一瞬で、しかも確実に行えるというメリットがあります。Cuncurrent VACUUMがすでに実装されている以上、それほど気にするべき要因ではないと思うのですが。

    一方、PostgreSQLのストレージ管理やバッファー管理は洗練されているとは決して言えないので、その点は歓迎出来ると思います。

    • by Anonymous Coward on 2003年05月20日 18時19分 (#319695)
      某自治体向けシステムに使われていたのを触っていた時は、
      あまりいい印象がなかったですね・・・・

      とにかくロックの制御がタコで、原因不明の解けないロック
      が多発してた。また、サーバ側にSQLコンソールがなくて、
      しょうがないので、自作ツールでクライアント側から、強制
      開放するか、サーバ側でisqlライクなPGにSQLコマンドファ
      イルを食わせるバッチファイルで処理してた。

      あと、このロックを強制開放すると、かならずテーブルのイ
      ンデックス等が壊れていた。で、個別&全テーブルのドロップ
      &定義&データ復旧用のバッチファイルが必須という情けない
      運用をしていた・・・

      動かしていたのは、NTで、元の主戦場のUXP/DSや、Sファミリ
      上では、もっとまともなのかもしれないが、あの経験をして
      いるので、使う気にはなれない・・・

      この方式だと、実質SQLの制御をするのは、Posgresのコード
      のようなので、苦労した点は改良されるということなのだろ
      うか?

      いずれにせよ、名前を聞くだけで憂鬱なのでAC
      親コメント
      • ロックですか・・・それはやっかいですね。

        PostgreSQLの行レベルロックはMVCCと密接に関係していて、PostgreSQLのMVCCは追記型ストレージと・・・ということになるので、解決にはならないかも知れません。

        ま、改善する部分もあるかと思いますが。

        親コメント
      • by Anonymous Coward on 2003年05月20日 19時56分 (#319748)
        データベースではないのですが、数年前 OLAP がちょっと話題に
        なっていた頃、同系列の Symfoware Navigator を使ったことが
        ありますが、製品と呼ぶにはあまりにバグが多く最悪の印象でし
        た。サポートもレスポンスが悪くおそまつだったし。

        # 当時は SymfoWARE と書いたような…
        # 私も名前を聞くと憂鬱になる
        親コメント
      • by Anonymous Coward on 2003年05月20日 21時25分 (#319820)

        富士通の二大巨頭と評されるSymfoWAREとSystemWalkerですが、私はSolaris版を触りましたが酷いもんでしたね。

        元レスの人も言ってますがサーバ内で一通り完結できるツールが揃ってないだけでなく(最近は触ってないのでわかりませんが)、自分(SymfoWARE)たちの都合しか考えていない妙な出来に悩まされました。インデックスが壊れるなんて日常茶飯事、酷いときには壊れたデータを読み出してきて正常動作してしまうなんてことも往々にしてありました。

        どちらかというと、SymfoWAREがPostgresの良いところを吸収してくれることを激しく望みます。現行のSymfoWAREの顧客からすればPostgresは「黒船来航」の如くでしょうから。

        親コメント
        • > 富士通の二大巨頭
          あと、InterStageもいれてはどうでしょう。これの商品体系も眩暈がするほどわかりにくいものですが。
          どれも自社提案案件でしか使われないってことは、品質は推して知るべし。

          #使わざるをえないのでAC
      • こういう独自系製品をオープン系に組み込む場合
        OracleとかSQLServerとの比較提案だったりすると非常に厳しい場合がありますよね
    • by Anonymous Coward on 2003年05月20日 23時02分 (#319900)
      インデックス用の領域を自分で計算して確保しなくちゃいけないのが萎え。
      SQL埋め込みCで書くと汚いし、INSERTが鬼のように遅いので萎え。
      コマンド体系や使い勝手がUnix思想を汲み取ってないので萎え。
      もう勘弁してくれ、って感じです。

      #仕事でつかってて泣きそうなのでAC
      親コメント
      • >インデックス用の領域を自分で計算して確保しなくちゃいけないのが萎え。

        #320324のACですが、私が導入で触ったシステムには、データの件数などを入力すると領域計算してSQL文を作ってくれるExcelのシートがツールとして付属してました。

        …でもそのまま使うと足りなくなるので、生成されたSQL文の数値を水増しして流してましたが。

    • by Anonymous Coward on 2003年05月21日 16時50分 (#320324)
      幸か不幸か開発でさわったことはないけど、富士通製自治体向けシステムの導入時にさわりました。
      他の方の例にもあるようにミドルウェアから富士通製品でぎっちり固められてました…って富士通が作ったシステムなんだからあたりまえか。

      私が触ったときは、一応SQLくらい流せるコンソールとか、運用保守に必要なツールくらいはあったので、その辺は進歩していたのかな?
      んでも原因不明のロックなんて良くありましたね。
      導入前に事前にデータをセットしようとして、いつのまにかロックしててハマったことが何度かありました。
      帰る前にデータ流して、次の日に終わってるかなと確認すると止まってたり。

      あとパフォーマンスも悪かったなぁ。
      DB直接たたいてもレスポンス悪いのにミドルウェア経由だと、もうもう「どうにかして~」って感じ。
      人口規模でハードの推奨スペックがあって、最初見たときに妙にハードル高いなと感じたのは、ソフトの遅さをハードで何とかしようとしてたみたいです…

      開発案件では選択したくないもののひとつ(って言うか筆頭?)です。

      親コメント
    • >一方、PostgreSQLのストレージ管理やバッファー管理は洗練されているとは決して言えないので、その点は歓迎出来ると思います。

      うーん、私としてはそういう洗練されたストレージ管理やバッファー管理が
      Postgresにフィードバックされると歓迎なんですが・・・
      • うーん、私としてはそういう洗練されたストレージ管理やバッファー管理がPostgresにフィードバックされると歓迎なんですが・・・
        洗練されているなら歓迎なのですけどね・・・せめてPostgreSQLよりは洗練されていると信じたいですけどね・・・

        なんか他の人の話を聞いていると、そうとも思えなくなってきました(汗

        親コメント
        • 洗練されているなら歓迎なのですけどね・・・せめてPostgreSQLよりは洗練されていると信じたいですけどね・・・
          PostgreSQLより朴訥なストレージやバッファ管理なんて無いと思いますけど・・・。
    • そもそも製品の提供する場合の立ち位置が微妙ですよね

      全然無関係の会社が、このDBをソリューションとして購入するのか?
      それとも富士通(や関連企業)が自前の案件で提案するのか?
      それによって、商品の見え方が全然ちがうような気がします。

      おそらく後者が殆どだろうけど・・・
    • 丁度、SymfowareとSymfoware Navigatorをコンボで使っています。
      開発のためにSQLを叩く必要があるのですが、当然のようにフリーソフト使ってます(お粗末)。

      Synfowareのロック関係の面倒さと、NavigatorがSynfowareと(必要な所で)連動していないのが

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

処理中...