パスワードを忘れた? アカウント作成
14666 story

FileMaker9はついにSQL Server対応? 40

ストーリー by mhatta
まだ噂だけどね 部門より

shunta 曰く、

Mac系噂サイトThinkSecretの記事によると、FileMakerは次期バージョンでSQL(ODBC)データソースへの対応を果たすようです。

もしこれが事実なら、MySQL(5.0)のフロントエンドとして、使いやすさに定評のあるFileMakerが利用できることになります。 これでXOOPSなどのCMSによって蓄積されたデータをFileMakerで手軽に活用できるのではないかと、アレゲにワクワクしませんか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • ODBCデータソース対応については、既に 現在のバージョンでも
    FileMaker社より公式のプラグインをダウンロードして 利用する
    ことができます。

    ただ、あまり安定しておらず、速度もでない、というのが印象で、
    たとえば MSAccess や Oracle の フロントエンドとして 使う、
    という案件で技術評価しましたが、業務には耐えない、という
    結論となりました。
    今回のバージョンで このあたりが解決してくれていれば いいですね。

    上記案件では、一度 CSVファイルにしてから読み込ませる、という
    フローで FileMakerを使うことにしました。巨大なファイルを扱わ
    ない限り、それなりに 使えるというのが印象です。
    • 私は元SEですが現在教育関連業務においてFileMaker5.5使ってる者です。その逆のフローでODBC使ってます。 VBからFMのデータの統計処理(計算フィールドとか使ってする気にならないクロス集計です)を行い、その結果を 人の目で見て判断しつつ、FMのデータにフィードバックさせるというやり方です。これもまた、とてつもなく 遅くて耐え難いものがあります。 これをスマートな形に解決するためには (a)FileMakerをVBAで操れるようになる (b)FileMakerがAccessでいう「リンクテーブル」をサポートする のどちらかを実現して欲しい…->FM社。これらが必要なデベロッパーの方、潜在的には結構いるのでは? web対応とか、FM単体でそこまでやらなくてもいいのではないかな。他のフロントエンドとの接続を確保してくれれば FM8.5だって買うかもしれないけどな。それがないならあくまで5.5の機能しかいりません。 しかしフロントエンドとしてのFMは捨てがたい。DB開発者の手を離れても、利用者が安全確実に改良できる 唯一のDBMSですから。 さらに地味で基本的な機能を充実して欲しい今日この頃です。
      親コメント
    • 上記案件でフロントエンドにFileMakerを採用された理由ってなんだったのでしょう?
      上記のようなケースの場合、さすがにFileMakerでは提案出来ません。
      差し支えなければで結構ですので、よろしくお願いします。
      • もともと VBとMS-Access+他DB がつながった業務システムがありまして、
        これに顧客先ですでにお使いになられていたMac向けの FileMakerのUIを
        統合してほしい、という依頼がありましたので、
        最初からFileMakerはマストだったわけです。
        統合するどちらのシステムも 完成度が高かったため、両者の変更は
        最小にする必要がありました。結果、CSV経由での通信を使った
        フロントエンド利用、ということになったわけです。
        #その際 かなりアクロバティックな動作をすること、については
        #顧客から同意をいただきました。

        結果できあがったものは、パッケージ化された業務システムに、
        顧客の必要なUIを載せる、というカスタマイズ性を最大限に
        活かせたシステムになり、ご好評をいただいております。

        FileMakerでは、外部DB連携に XML/SOAPを用いたソリューションも可能ですが、
        やはり処理効率から行って、CSVが一番速く、手っ取り早いという結論です。
        親コメント
  • FileMakerが優れたインターフェースを持ったデータベースアプリケーションであることに異存はないんだけど、それは主として「使いながら発展させる」ということがやりやすいからだと思うのね。最初に覚えないといけないことが少ないので、データベースは初めてという人にすすめやすい。そして使っているうちにデータベースってどういうものか、わかってくるというね。

    でも、RDBMSってのは、スキーマを頻繁に変更するような使い方をするものじゃない。スキーマを変更しても問題ないのは、利用者が限られている場合であって、複数のアプリケーションが参照するようなデータベースのスキーマはそうそう簡単には変更できないよね?スキーマを変更できないデータベースのフロントエンドとしては、別にFileMakerにアドバンテージはないと思う。AccessでもVBで書いたアプリでも、別に何でも同じ。もしあなたがXOOPSのバックエンドをFileMakerで覗いて嬉しかったら、別にAccessでも満足できたと思うけど。

  • FileMaker Serverは? (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2007年02月18日 12時02分 (#1111923)
    今までFileMakerで小規模に運用していたシステムをWebに移行したいと言われ、FileMaker Serverを導入してみたんだが、PHP + ODBCで値を引っ張ってこうよるとしてもいまいちパフォーマンスが悪くて使い物にならなかった。

    結局、カスタムWeb公開機能のXMLを取得してくるようにして(FX.php等で)解決したんだが、XMLくらいしかまともに使えそうなものがないというのは何とかして欲しい。30万も払ったのに…。

    そもそも、カスタムWebのXML + XSLTでまともにページ作ってる奴なんて存在するのだろうか。
    XSLTを生で書こうとするなんてマゾだと思うんですけどね。

    FileMaker ServerもPHPやPerl等からまともに使えるようにして欲しいと思ったり、思わなかったり。
    • by vn (10720) on 2007年02月18日 12時16分 (#1111926) 日記
      FileMaker ServerもPHPやPerl等からまともに使えるようにして欲しいと思ったり、思わなかったり。
      FileMaker のデータベースに Perl からアクセスしたかったら、
      DBD::JDBC を経由すればいいんじゃないの? サーバである必要はないし。
      「まとも」かどうかは全然知らないけれど。
      親コメント
    • by Anonymous Coward on 2007年02月18日 20時40分 (#1112077)
      経験から断言しますが、そういう規模の案件になった時点でFileMakerは捨てて他のRDBMSに移行するのが結果的に一番コストが安くつくケースが多いです。
      FileMakerはあくまでクライアントまで全てFileMakerで運用する小規模運用を対象とした製品であって、バックエンドに使うメリットは殆どありません。むしろバージョンが上がるたびに振り回される、ちょっとしたことでも機能不足を補うためにアクロバティックなやり方を強いられますし。そもそも大量データや無停止運用に向いていない。外部のDBにSQLでアクセスできるかどうかなんてのは些細な話。
      やっぱりFileMakerが一番強みを発揮するのは、ちょっとしたデータを自分で作って自分で使うというような用途ですね。そういう用途では非常に優れた製品だと思います。
      親コメント
      • by Anonymous Coward
        >そういう規模の案件になった時点でFileMakerは捨てて他のRDBMSに移行するのが

        すみません。FileMakerのことは何も知らないので外してたら申し訳ないのですが、
        そういう話を聞くたびについ思うのが、
        「そもそもそのデータはRDBMSに移行可能なのか?」
        という疑問です。

        やっぱりRDBってのは「かたい」データベースなので、
        よほど念入りに作ったスキーマでないと、
        運用してて使いものにならなくなるんですよね。

        #そうでなきゃRDB(SQL)技術者なんてものが別途必要になるはずがない。

        それも新規案件ならばまあ最初から気をつかえば済むことなんですが、
        問題なのは以前から非RDBでデータ管理してて
        (
        • by Anonymous Coward
          >「そもそもそのデータはRDBMSに移行可能なのか?」

          「かたい」DBという意味を後からの仕変に対する柔軟性がないという意味合いとするならば、そもそもFileMakerの外部の、先の例で言えばPHPなどと連携し始めた時点で既に崩れている話なんです。FileMaker+PHPが「かたくない」というのであれば、それはFileMakerを他のRDBMSに置き換えたからといって「かたくなる」訳じゃありません。DBエンジン自体の機能の差によってはむしろ「やわらかくなる」。
          だから、そのように外部のプログラムと連携を始める時は思い切るチャンスというのが私の経験則です。
          もちろん、どんな場合でも例外なく常にそうである、と主張するものではありませんが。
          • by Anonymous Coward
            >FileMakerを他のRDBMSに置き換えたからといって「かたくなる」訳じゃありません

            それはまあそうなんですけどね。

            正規化もへったくれもない、論理的にあとあと収集が付かなくなるのが落ちなデータを
            そのまま(収集させるコストを度外視して)RDBに乗り換えさせる、という自由は、いちおう有りますから。

            こんにちにおいてRDBのほうが「確実に優位」だと言い切れるのは、
            (選択肢が多いことから来る)スケーラビリティなどの
            物理的な面だけかと思います。

            ところで、正規化みたいなものに対する要求というか「圧力」は、
            FileMakerではどれくらい強かったのでしょうか?
      • by Anonymous Coward
        >経験から断言しますが、

        現行のFileMaker Serverを「知らない」と言っているようなもんです。
        中規模程度までは十分に対応出来る処理能力とスピードを現在は備えて
        いるし、作り方と運用次第という意味では、他のRDBMSよりも優位です。
        ショッピングサイトを運用しているところも多いし、先日はアンケート
        システムでも見かけましたが、良く出来ていてレスポンスも快適でした。
        個人向けが出発点ですが、今はビジネス用途製品なので当たり前ですが。
        • by Anonymous Coward
          FileMaker Serverですか。5.5から以降、ころころとプロダクト仕様を変えていただきまして大変勉強させられました。個人的に言わせていただければ、あのような腰の据わらないものはパフォーマンス以前のところで仕事で使いたくはないです。

          使い方と運用次第の条件を付けるならどんな製品だって有利と言える気がしますが、それはそれとしてフロントエンドがFileMaker以外の中規模以上のシステムにおいて、バックエンドにFileMaker Serverを使うことで他のRDBMS製品より有利な理由が特に思いつきません。具体的に何がありますでしょうか?

    • by Anonymous Coward
      FileMaker API for PHP パブリックベータ
      http://www.filemaker.co.jp/developers/resources/php/index.html [filemaker.co.jp]
      なんてのがありますよ。
      Zend PHP の企業パートナーにもなってますし。
      http://www.zend.com/news/zendpr.php?id=109 [zend.com]
      • by Anonymous Coward
        パブリックベータなんて流石に仕事にゃ使えませんよ。

        それトラブった時の対処は全部自分持ちって言っている様なものだもの。

        • by Anonymous Coward
          今はまだパブリックベータですが、方向性を示していると思います。
          そしてなによりZendコミュニティにコミットしたことが重要かと。
  • by corymania (33448) on 2007年02月18日 16時13分 (#1111995) ホームページ
    FileMakerで作成されていたデータを
    Excelで吸い出して加工したいといわれて
    ODBC経由で吸い出すものを作ったものの…

    案件担当者がなぜか刑事告訴されて案件自体なくなった…
    報酬もろくに出なかったけど
    まぁ、実害がなかっただけもうけもの

    実際は動作が重くて自分では使いたくないものでした




    真っ白なキャンバスをカルマで染めて・・・
  • SQLサーバ?? (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2007年02月18日 11時41分 (#1111921)
    >ついにSQL Server対応?

    その言い回しを聞くと、どうも
    MS SQL Serverという特定商品を思い出してしまうのですが(^^;。

    今回のって、ODBCっていう話なのですよね?だとすれば別の話ですよね。
    (ODBC自体にもMSの息はかかってるがそれはともかく)

    ところで、そんなMS「SQL」Serverが、
    SQL(言語としての)離れを始めようとしてるってのは、
    興味深いです。
    .NETで書いたコードをServerの中で使えるとか、LINQだとか、
    少しづつ脱SQLをやってますね。
    SQLは言語仕様として古すぎて使いにくい面が結構あるんで、
    こういう動きは歓迎したいです。
    ただ、例によってMSだってのがちょっとね。
    ポスグレやMySQLもそういうことをやってくれよ(^^;

    #SQLはUNIXみたいな意味でのフィルタが書けないのが致命的だと思うのでAC
    #Viewも「その入力が何なのか」はView内にハードコーディングしないとならない(T_T)
    • by Ying (4319) on 2007年02月19日 8時58分 (#1112267)
      というか、リンク先を読んだ限りでは、
      • FileMakerがODBC経由でのRDBMSへの接続をサポートする
      • ODBC経由での接続先として、SQL Server 2000 and 2005, Oracle 9g and 10g, MySQL 5.0を公式にサポートする
      というような話のようなので、まさしく
      MS SQL Serverという特定商品
      についての話かと思いますが。
      親コメント
typodupeerror

人生unstable -- あるハッカー

読み込み中...