FileMaker9はついにSQL Server対応? 40
ストーリー by mhatta
まだ噂だけどね 部門より
まだ噂だけどね 部門より
shunta 曰く、
Mac系噂サイトThinkSecretの記事によると、FileMakerは次期バージョンでSQL(ODBC)データソースへの対応を果たすようです。
もしこれが事実なら、MySQL(5.0)のフロントエンドとして、使いやすさに定評のあるFileMakerが利用できることになります。 これでXOOPSなどのCMSによって蓄積されたデータをFileMakerで手軽に活用できるのではないかと、アレゲにワクワクしませんか?
現在のバージョンでもODBC対応できていますが... (スコア:5, 参考になる)
FileMaker社より公式のプラグインをダウンロードして 利用する
ことができます。
ただ、あまり安定しておらず、速度もでない、というのが印象で、
たとえば MSAccess や Oracle の フロントエンドとして 使う、
という案件で技術評価しましたが、業務には耐えない、という
結論となりました。
今回のバージョンで このあたりが解決してくれていれば いいですね。
上記案件では、一度 CSVファイルにしてから読み込ませる、という
フローで FileMakerを使うことにしました。巨大なファイルを扱わ
ない限り、それなりに 使えるというのが印象です。
Re:現在のバージョンでもODBC対応できていますが... (スコア:1)
Re:現在のバージョンでもODBC対応できていますが... (スコア:0)
上記のようなケースの場合、さすがにFileMakerでは提案出来ません。
差し支えなければで結構ですので、よろしくお願いします。
Re:現在のバージョンでもODBC対応できていますが... (スコア:2, 興味深い)
これに顧客先ですでにお使いになられていたMac向けの FileMakerのUIを
統合してほしい、という依頼がありましたので、
最初からFileMakerはマストだったわけです。
統合するどちらのシステムも 完成度が高かったため、両者の変更は
最小にする必要がありました。結果、CSV経由での通信を使った
フロントエンド利用、ということになったわけです。
#その際 かなりアクロバティックな動作をすること、については
#顧客から同意をいただきました。
結果できあがったものは、パッケージ化された業務システムに、
顧客の必要なUIを載せる、というカスタマイズ性を最大限に
活かせたシステムになり、ご好評をいただいております。
FileMakerでは、外部DB連携に XML/SOAPを用いたソリューションも可能ですが、
やはり処理効率から行って、CSVが一番速く、手っ取り早いという結論です。
FileMakerの強みは感覚的に使えること (スコア:2, すばらしい洞察)
FileMakerが優れたインターフェースを持ったデータベースアプリケーションであることに異存はないんだけど、それは主として「使いながら発展させる」ということがやりやすいからだと思うのね。最初に覚えないといけないことが少ないので、データベースは初めてという人にすすめやすい。そして使っているうちにデータベースってどういうものか、わかってくるというね。
でも、RDBMSってのは、スキーマを頻繁に変更するような使い方をするものじゃない。スキーマを変更しても問題ないのは、利用者が限られている場合であって、複数のアプリケーションが参照するようなデータベースのスキーマはそうそう簡単には変更できないよね?スキーマを変更できないデータベースのフロントエンドとしては、別にFileMakerにアドバンテージはないと思う。AccessでもVBで書いたアプリでも、別に何でも同じ。もしあなたがXOOPSのバックエンドをFileMakerで覗いて嬉しかったら、別にAccessでも満足できたと思うけど。
Re:FileMakerの強みは感覚的に使えること (スコア:2, すばらしい洞察)
当時としては、(某少佐のセリフを借りればw)エンドユーザに「素直にパーソナルDBのありようを示した」画期的なソフトの出現だった。
時代は移り変わって、FileMakerも自分自身のフォロワー(Access等)に負けないように機能追加をして生き延びてきてはいるけれども、
それもFileMakerが作り出したパラダイムの中でのマイナーな変化にすぎず、今回のODBC対応もゆるやかな延命措置にすぎない感じは拭えません。
ご指摘のようにRDBMSのフロントエンドとして生き残れるかというと、ちょっと難しい。せいぜい既存ユーザのフロントエンドの選択肢が増える程度かも。
振り返ってみると、FileMakerその他が開拓したパーソナル向けDBの市場というものも、昔と比べてさほど大きくなっている感じもしないし、
逆に個人向けに限ってしまえば、情報管理の仕方も、定型的・固定的な枠組みでデータを蓄積・検索するのではなく、
Mac OS XのSpotlightやGoogleデスクトップ検索のような全文検索やメタデータによる管理方法の方が大きく取り扱われているような気がします。
ですので、いっそのことFileMakerもOS Xのファイルシステムのメタデータを扱えるようになったりすると、非常に面白いかもと思ったりするんですよね。
そうなればiTunesやiPhotoのメタデータにもアクセスできるでしょうし、Spotlight検索にも対応できる独自メタデータを扱えたりと、
OS Xのメタデータ管理機能を活かすフロントエンドになるような気もするんですが。。。
Re:FileMakerの強みは感覚的に使えること (スコア:2, 興味深い)
(ユーザ以外には良さが理解されていない)孤高の存在であることには
違いないでしょう。パラダイムシフトはFileMaker 7で起きています。
その土台があるからこそ、SQL対応も果たせるようになるのでしょう。
Re:FileMakerの強みは感覚的に使えること (スコア:0)
そして今後は全文検索やメタデータに移行したほうがいいということにも同意。
旧来のSQL系RDBMSとこれからのメタデータ系DBMSをシームレスに扱えるツールになったらいいよねぇ。
Re:FileMakerの強みは感覚的に使えること (スコア:1)
Re:FileMakerの強みは感覚的に使えること (スコア:0)
Re:FileMakerの強みは感覚的に使えること (スコア:2, おもしろおかしい)
#はっ、動作環境がないぞ!
Re:FileMakerの強みは感覚的に使えること (スコア:0)
とはいっても、本で読んだだけですけどねー。
Re:FileMakerの強みは感覚的に使えること (スコア:1)
Re:FileMakerの強みは感覚的に使えること (スコア:1, おもしろおかしい)
| 次でボケて!!! |
|________|
∧∧ ||
( ゚д゚)||
/ づΦ
Re:FileMakerの強みは感覚的に使えること (スコア:1)
MS SQL限定だけどAccessと同じ感じでSQL組み立てて簡単に組めたり。
Re:FileMakerの強みは感覚的に使えること (スコア:0)
Re:FileMakerの強みは感覚的に使えること (スコア:0)
Re:FileMakerの強みは感覚的に使えること (スコア:0)
Re:FileMakerの強みは感覚的に使えること (スコア:0)
Re:FileMakerの強みは感覚的に使えること (スコア:0)
Re:FileMakerの強みは感覚的に使えること (スコア:0)
Re:FileMakerの強みは感覚的に使えること (スコア:0)
FileMaker Serverは? (スコア:2, すばらしい洞察)
結局、カスタムWeb公開機能のXMLを取得してくるようにして(FX.php等で)解決したんだが、XMLくらいしかまともに使えそうなものがないというのは何とかして欲しい。30万も払ったのに…。
そもそも、カスタムWebのXML + XSLTでまともにページ作ってる奴なんて存在するのだろうか。
XSLTを生で書こうとするなんてマゾだと思うんですけどね。
FileMaker ServerもPHPやPerl等からまともに使えるようにして欲しいと思ったり、思わなかったり。
Re:FileMaker Serverは? (スコア:1)
DBD::JDBC を経由すればいいんじゃないの? サーバである必要はないし。
「まとも」かどうかは全然知らないけれど。
Re:FileMaker Serverは? (スコア:1, 参考になる)
FileMakerはあくまでクライアントまで全てFileMakerで運用する小規模運用を対象とした製品であって、バックエンドに使うメリットは殆どありません。むしろバージョンが上がるたびに振り回される、ちょっとしたことでも機能不足を補うためにアクロバティックなやり方を強いられますし。そもそも大量データや無停止運用に向いていない。外部のDBにSQLでアクセスできるかどうかなんてのは些細な話。
やっぱりFileMakerが一番強みを発揮するのは、ちょっとしたデータを自分で作って自分で使うというような用途ですね。そういう用途では非常に優れた製品だと思います。
Re:FileMaker Serverは? (スコア:0)
すみません。FileMakerのことは何も知らないので外してたら申し訳ないのですが、
そういう話を聞くたびについ思うのが、
「そもそもそのデータはRDBMSに移行可能なのか?」
という疑問です。
やっぱりRDBってのは「かたい」データベースなので、
よほど念入りに作ったスキーマでないと、
運用してて使いものにならなくなるんですよね。
#そうでなきゃRDB(SQL)技術者なんてものが別途必要になるはずがない。
それも新規案件ならばまあ最初から気をつかえば済むことなんですが、
問題なのは以前から非RDBでデータ管理してて
(
Re:FileMaker Serverは? (スコア:0)
「かたい」DBという意味を後からの仕変に対する柔軟性がないという意味合いとするならば、そもそもFileMakerの外部の、先の例で言えばPHPなどと連携し始めた時点で既に崩れている話なんです。FileMaker+PHPが「かたくない」というのであれば、それはFileMakerを他のRDBMSに置き換えたからといって「かたくなる」訳じゃありません。DBエンジン自体の機能の差によってはむしろ「やわらかくなる」。
だから、そのように外部のプログラムと連携を始める時は思い切るチャンスというのが私の経験則です。
もちろん、どんな場合でも例外なく常にそうである、と主張するものではありませんが。
Re:FileMaker Serverは? (スコア:0)
それはまあそうなんですけどね。
正規化もへったくれもない、論理的にあとあと収集が付かなくなるのが落ちなデータを
そのまま(収集させるコストを度外視して)RDBに乗り換えさせる、という自由は、いちおう有りますから。
こんにちにおいてRDBのほうが「確実に優位」だと言い切れるのは、
(選択肢が多いことから来る)スケーラビリティなどの
物理的な面だけかと思います。
ところで、正規化みたいなものに対する要求というか「圧力」は、
FileMakerではどれくらい強かったのでしょうか?
Re:FileMaker Serverは? (スコア:0)
現行のFileMaker Serverを「知らない」と言っているようなもんです。
中規模程度までは十分に対応出来る処理能力とスピードを現在は備えて
いるし、作り方と運用次第という意味では、他のRDBMSよりも優位です。
ショッピングサイトを運用しているところも多いし、先日はアンケート
システムでも見かけましたが、良く出来ていてレスポンスも快適でした。
個人向けが出発点ですが、今はビジネス用途製品なので当たり前ですが。
Re:FileMaker Serverは? (スコア:0)
使い方と運用次第の条件を付けるならどんな製品だって有利と言える気がしますが、それはそれとしてフロントエンドがFileMaker以外の中規模以上のシステムにおいて、バックエンドにFileMaker Serverを使うことで他のRDBMS製品より有利な理由が特に思いつきません。具体的に何がありますでしょうか?
Re:FileMaker Serverは? (スコア:0)
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]
Re:FileMaker Serverは? (スコア:0)
それトラブった時の対処は全部自分持ちって言っている様なものだもの。
Re:FileMaker Serverは? (スコア:0)
そしてなによりZendコミュニティにコミットしたことが重要かと。
強要されて・・・ (スコア:2, 興味深い)
Excelで吸い出して加工したいといわれて
ODBC経由で吸い出すものを作ったものの…
案件担当者がなぜか刑事告訴されて案件自体なくなった…
報酬もろくに出なかったけど
まぁ、実害がなかっただけもうけもの
実際は動作が重くて自分では使いたくないものでした
真っ白なキャンバスをカルマで染めて・・・
余計なお世話だとは思うが (スコア:1)
#これはほら、老婆心ってやつだ
Re:余計なお世話だとは思うが (スコア:0)
署名の通りからっぽのキャンパスの持ち主ゆえ
若気の至りぢゃないですが。。。
といまさらACで返事を書いてみるテスト
SQLサーバ?? (スコア:1, すばらしい洞察)
その言い回しを聞くと、どうも
MS SQL Serverという特定商品を思い出してしまうのですが(^^;。
今回のって、ODBCっていう話なのですよね?だとすれば別の話ですよね。
(ODBC自体にもMSの息はかかってるがそれはともかく)
ところで、そんなMS「SQL」Serverが、
SQL(言語としての)離れを始めようとしてるってのは、
興味深いです。
.NETで書いたコードをServerの中で使えるとか、LINQだとか、
少しづつ脱SQLをやってますね。
SQLは言語仕様として古すぎて使いにくい面が結構あるんで、
こういう動きは歓迎したいです。
ただ、例によってMSだってのがちょっとね。
ポスグレやMySQLもそういうことをやってくれよ(^^;
#SQLはUNIXみたいな意味でのフィルタが書けないのが致命的だと思うのでAC
#Viewも「その入力が何なのか」はView内にハードコーディングしないとならない(T_T)
Re:SQLサーバ?? (スコア:1)